I always thought it was interesting that my modern CPU takes ages to plot 100,000 or so points in R or Python (ggplot2, seaborn, plotnine, etc) and yet somehow my 486DX 50Mhz could pump out all those pixels to play Doom interactively and smoothly.
Fastplotlib: GPU-accelerated, fast, and interactive plotting library
141–150 of 190 posts
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#142How is it compared to HoloViz?[1]
I followed one of their online workshops, and it feels really powerful, although it is a bit confusing which part of it does what (it's basically 6 or 7 projects put together under an umbrella)
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#143Looks very interesting. Does it allow to plot lines of varying thickness?
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#144Earlier quoted context omitted.
>> 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.
But why do you want to fit the whole dataset in memory? If the dataset is stored in a tiled and multi-scaled representation you need to only grab the part of it that is needed to fit your screen (which is a constant, small amount of data, even if the dataset is arbitrarily large).
If you insist to fit the entire thing in memory, it may seem better to do so in the plain RAM, which nowadays is of humongous size even in "modest" systems.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#145How is it compared to HoloViz?[1] I followed one of their online workshops, and it feels really powerful, although it is a bit confusing which part of it does what (it's basically 6 or 7 projects put together under an umbrella) [1] https://holoviz.org/
One big difference is that Fastplotlib is based on GPU tech, so its capable of rendering much larger datasets interactively.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#146> 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.
To clarify this a bit, wgpu is a Rust implementation of WebGPU, just like Dawn is a C++ implementation of WebGPU (by Google). Both projects expose a C-api following webgpu.h. wgpu-py Should eventually be able to work with both. (Disclaimer: I'm the author of wgpu-py)
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#147One of the big bottlenecks of plotting libraries is simply the time it takes to import the library. I’ve seen matplotlib being slow to import, and in Julia they even have a “time to first plot” metric. I’d be curious to see how this library compares.
I have a feeling there's room for improvement for importing Pygfx as well. I think we should indeed strive that simple plots load super-quick.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#148Yeah, many browsers have webgpu turned off by default, So you're stuck with wasm (wasm Simd if you're lucky) Hopefully both are implemented.
That's because WebGPU is still experimental. This will change, as it's set to replace WebGL.
Fastplotlib / pygfx are primarily meant to run on desktop. When using it via the notebook the server does the rendering.
As Ivo said, we have plans to support running in the browser via Pyodide, which opens some interesting things, but is not the primary purpose.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#149"Fast" is a bold claim, given the complete lack of benchmarks and the fact that it's written entirely in Python...
I'm certain the host heavy lifting is done by numpy which is a python wrapper around Fortran and C. The visualization heavy lifting is done by pygfx/wgpu-py. wgpu-py has C. I think wgpu-py compiles to WASM to run in the browser. More and more packages are taking this route. [1] https://github.com/pygfx/pygfx [2] https://github.com/pygfx/wgpu-py
All true, except the bit that wgpu-py compiles to WASM. It's all desktop.
In the plans that we do have for running the browser, Fastplotlib, Pygfx and wgpy-py will still be Python, running on CPython that is compiled to WASM (via Pyodide). But instead of wgpu-py cffi-ing into a C library, it would make JS calls to the WebGPU API.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#150I always thought it was interesting that my modern CPU takes ages to plot 100,000 or so points in R or Python (ggplot2, seaborn, plotnine, etc) and yet somehow my 486DX 50Mhz could pump out all those pixels to play Doom interactively and smoothly.
This SO thread [1] analyses how much time ggplot spends on various tasks. Not sure if a better GPU integration to produce the visual output would help speed it up significantly.
[1] https://stackoverflow.com/questions/73470828/ggplot2-is-slow...