Live data from Hacker News

Fastplotlib: GPU-accelerated, fast, and interactive plotting library

medium.com

121–130 of 190 posts

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#121

I’m often working with a windows desktop and a remote Linux box on which I have my data & code. I’d like to plot “locally” on my desktop workstation from the remote host. This usually either means using X11 (slow) or some sort of web-based library like plotly. Does fastplotlib offer any easy solution here?

This is exactly why we use jupyter-rfb, I often have large datasets on a remote cluster computer and we perform remote rendering. see: https://fastplotlib.org/ver/dev/user_guide/faq.html#what-fra...

I'm in the same boat as the person you replied to, but have zero experience with remote plotting other that doing static plots in in a remote session in the interactive window provided by VS Code's python extension. Would this also work there, or would I have to start using jupyter notebooks?

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#122
> powered by WGPU, a cross-platform graphics API that targets Vulkan (Linux), Metal (Mac), and DX12 (Windows).

The fact that they are using WGPU, which appears to be a Python native implementation of WebGPU, suggests there is an interesting possible extended case. As a few other comments suggest, if one knows that the data is available on a machine in a cluster rather than on the local machine of a user, it might make sense to start up a server, expose a port and pass along the data over http to be rendered in a browser. That would make it shareable across the lab. The limit would be the data bandwidth over http (e.g. for the 3 million point case) but it seems like for simpler cases it would be very useful.

That would lead to an interesting exercise of defining a protocol for transferring plot points over http in such a way they could be handed over to a the browser WebGPU interface efficiently. Perhaps even a more efficient representation is possible with some pre-processing on the server side?

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#123

> powered by WGPU, a cross-platform graphics API that targets Vulkan (Linux), Metal (Mac), and DX12 (Windows). The fact that they are using WGPU, which appears to be a Python native implementation of WebGPU, suggests there is an interesting possible extended case. As a few other comments suggest, if one knows that the data is available on a machine in a cluster rather than on the local machine of a user, it might mak…

WGPU is a Rust thing more than a Python thing.

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#124
post #123

> powered by WGPU, a cross-platform graphics API that targets Vulkan (Linux), Metal (Mac), and DX12 (Windows). The fact that they are using WGPU, which appears to be a Python native implementation of WebGPU, suggests there is an interesting possible extended case. As a few other comments suggest, if one knows that the data is available on a machine in a cluster rather than on the local machine of a user, it might mak…

WGPU is a Rust thing more than a Python thing.

Fair, I was looking at the wgpu-py [1] page but only skimmed it. It does indeed look like a wrapper over wgpu-native [2] which is written in Rust.

1. https://github.com/pygfx/wgpu-py

2. https://github.com/gfx-rs/wgpu-native

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#125

That would be preposterous if it wasn't so hilariously false: > These days, having a GPU is practically a prerequisite to doing science, and visualization is no exception. It becomes really funny when they go on to this, as if it was a big deal: > Depicted below is an example of plotting 3 million points Anybody who has ever used C or fortran knows that a modern CPU can easily churn through "3 million points" at more…

>> Depicted below is an example of plotting 3 million points

> Anybody who has ever used C or fortran knows that a modern CPU can easily churn through "3 million points" at more than 30 frames per second, using just one thread. It's not a particularly impressive feat, three million points is the size of a mid-resolution picture, and you can zoom-in and out those trivially in real-time using a CPU (and you could do that 20 years ago, as well). Maybe the stated slowness of fastplotlib comes from the unholy mix of rust and python?

That's a misrepresentation though, it's 3 million points in sine waves, e.g. something like 1000 sine waves with e.g. 3000 points in each. If you look at the zoomed in image, the sine waves are spaced significantly, so if you would represent this as an image it would be at least a factor 10 larger. In fact that is likely a significant underestimation, i.e. you need to connect the points inside the sine waves as well.

The comparison case would be to take a vector graphics (e.g. svg) with 1000 sine wave lines and open it in a viewer (written in C or Fortran if you want) and try zooming in and out quickly.

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#126
post #21

Shameless plug: I'm actively working on a similar project, Datoviz [1], a C/C++ library with thin Python bindings (ctypes). It supports both 2D and 3D but is currently less mature and feature-complete than fastplotlib. It is also lower level (high-level capabilities will soon be provided by VisPy 2.0 which will be built on top of Datoviz, among other possible backends). My focus is primarily on raw performance, visua…

Cool to see you on here Cyrille, I've been following your work (and Nicolas's) for a long time. Thanks for all the cool stuff you've been doing!

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#127

That would be preposterous if it wasn't so hilariously false: > These days, having a GPU is practically a prerequisite to doing science, and visualization is no exception. It becomes really funny when they go on to this, as if it was a big deal: > Depicted below is an example of plotting 3 million points Anybody who has ever used C or fortran knows that a modern CPU can easily churn through "3 million points" at more…

>> Depicted below is an example of plotting 3 million points > Anybody who has ever used C or fortran knows that a modern CPU can easily churn through "3 million points" at more than 30 frames per second, using just one thread. It's not a particularly impressive feat, three million points is the size of a mid-resolution picture, and you can zoom-in and out those trivially in real-time using a CPU (and you could do th…

Thanks, and the purpose was to show what's possible on modest hardware that most people have. We have created gigabytes of graphics that live on the gpu for more complex use cases and they remain performant, but you need a gaming gpu.

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#129

Sometimes I wish these plotting libraries were more portable beyond Python only. I was looking for something similar for Ruby just a while ago but the install instructions seemed out of date and unsupported on Windows.

Any sufficiently advanced plotting library with an api that can be called externally becomes indistinguishable from a GUI toolkit: https://www.gnu.org/software/guile/docs/guile-tut/tutorial.h...

Not sure if that is the right tutorial, but many years ago in the guile 1.x days I wrote a local visualizer for the data from a particle physics accelerator entirely in Guile and Gnuplot. It was very MVC and used guile as the controller and Gnuplot as the viewer.

Was it stupid? Yes. Did it work better than all the other tools I had at the time? Also yes.

Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library

#130

Sometimes I wish these plotting libraries were more portable beyond Python only. I was looking for something similar for Ruby just a while ago but the install instructions seemed out of date and unsupported on Windows.

I do not know ruby but sometimes that's an opportunity to try and make one which others will also find useful :)
Post reply on HN