Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

161–170 of 190 posts

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

#161

Post by menaerus »

jampekka wrote: post #156
menaerus wrote: post #153

Earlier quoted context omitted.

> of complicated APIs of which the matplotlib is the embodiment. Terrible API with terrible terrible performance.

Not sure what you mean by complicated API. The (pylab) API is a very straightforward (mostly) immediate rendering typeish interface, with a lot of convenient shortcuts for operations used a lot in data analysis. For architecture astronauts there's also the OOP API over which the pylab API is a wrapper. Of course there are also a lot of all sorts of declarative APIs, which are popular with people copy-pasting code fro…

Just my personal experience from using the library for at least 7-8 years. So many things and concepts are glued onto each other, making the API so much non-intuitive whenever you try to do anything more sophisticated that isn't a 1:1 match from examples found in the cookbook. It's really a PITA and performance, I have to say this again, is really really bad. If this had been part of my daily job I would certainly try to switch to something else.

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

#162

Post by kkoncevicius »

dcl wrote: post #141

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.

From R side i think this is mainly because ggplot2 is really really slow.

Base R graphics would plot 100,000 points in about 100 milliseconds.

    x
A quick benchmark with writing to a file:

    x

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

#163

Post by jampekka »

menaerus wrote: post #161
jampekka wrote: post #156

Earlier quoted context omitted.

Not sure what you mean by complicated API. The (pylab) API is a very straightforward (mostly) immediate rendering typeish interface, with a lot of convenient shortcuts for operations used a lot in data analysis. For architecture astronauts there's also the OOP API over which the pylab API is a wrapper. Of course there are also a lot of all sorts of declarative APIs, which are popular with people copy-pasting code fro…

Just my personal experience from using the library for at least 7-8 years. So many things and concepts are glued onto each other, making the API so much non-intuitive whenever you try to do anything more sophisticated that isn't a 1:1 match from examples found in the cookbook. It's really a PITA and performance, I have to say this again, is really really bad. If this had been part of my daily job I would certainly tr…

Performance for animation and (custom) interaction is a real problem. But as for performance being "really really bad", there are not many widely used plotting libraries faster than it, at least for static plotting and zoom/pan interaction.

There are indeed many ad-hoc functions, typically for commonly used cases, and they tend to cover vast majority of common use case with very simple and concise code. If you want something more custom, the underlying artist API is very flexible. But you probably know this based on the 7-8 years?

Things like subplot layouts, data point annotation and legend tweaking can be really painful. Something like a proper box/model CSS layouting would be great.

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

#164

Post by dan-robertson »

vibranium wrote: post #114

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?

I’ve found X11 to be fine, but:

- defaults are often bad. In R there is a way to turn on double-buffering in Cairo to make things fast

- eventually so went for R-inside-orgmode where graphics are written to pngs (fast) and then displayed inside Emacs (fast over X forwarding so long as you aren’t trying to smooth-scroll with an image half-visible in the current window).

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

#165

Post by rossant »

cycomanic wrote: post #126
rossant wrote: 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!

Thank you!

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

#166

Post by rossant »

rossant wrote: post #84
Spoilage4218 wrote: post #29

Earlier quoted context omitted.

I have always admired your datoviz library from afar and check the vispy2/vispy2-sandbox libraries on GitHub every few months to check up on it. When do you think 'soon' is?? Really looking forward to it!

Thanks! The code is currently managed by Nicolas Rougier in a GitHub repository that will be made public next week. This repository hosts the "graphics server protocol" (GSP), an intermediate layer between Datoviz and the future high-level plotting API. For the latter, we’ll need community feedback to shape an API philosophy that aligns with VisPy users' needs—let's aim to publish a write-up this month. Implementing…

I wrote a quick draft outlining the vision here. [1]

[1] https://github.com/vispy/vispy2/blob/main/ARCHITECTURE.md

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

#168

Post by anthk »

Here people using tons of GB and VRAM for tasks I just used awk and gnuplot on really underpowered machines. Such as the guys who parsed GB sized texts files ('big data', you know) containing IPs and Cloudflare hosts (due to LaLiga scandal blocking whole CF IP's because some of them they were user for soccer TV broadcasting piracy) by using CUDA and some bullshit, when the same tasks could be done with mawk in less than an hour.

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

#169

Post by swalsh »

CreRecombinase wrote: post #12

Every two weeks or so I peruse github looking for something like this and I have to say this looks really promising. In statistical genetics we make really big scatterplots called Manhattan plots https://en.wikipedia.org/wiki/Manhattan_plot and we have to use all this highly specialized software to visualize at different scales (for a sense of what this looks like: https://my.locuszoom.org/gwas/236887/ ). Excited to…

These really large scatterplots are also useful for visualizing claims, and finding fraud.

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

#170

Post by fransje26 »

jampekka wrote: post #158
fransje26 wrote: post #157

Earlier quoted context omitted.

> Don't fix what's not broken. I would argue that the Matplotlib syntax is horribly broken (or rather, the Matlab syntax it historically tried to emulate, and had to stick with for better or worse..)

What are your issues with the matplotlib API more specifically?

Complaining about the inconsistencies of the matplotlib interface is pretty much beating a dead horse by now, and has been done repeatedly and in detail by others.

The problems start as soon as you try doing something more than plt.plot(), and you get your first encounter with the maddening interface differences between a single figure plot and a multi-figure plot. And then it spirals out of control from there.

There is no denying that a lot of effort was put in the library over the years, with lots of documentation and examples, but my general experience over the 15 years I've been using it is that as soon as you try doing something slightly different than the defaults, it invariably turns out to be a time-consuming, frustrating endeavour, with no guarantees that you'll get the result you want.

Post reply on HN