> 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.
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.
But with 10 billion points, you need to consider more sophisticated approaches.
#define FPS 80
void plot_points(
float *o, // output raster array (w*h)
int w, // width of raster
int h, // height of raster
float *x, // input point coordinates (2*n)
int n // number of input points
)
{
// initialize the output raster
for (int i = 0; i < 2*w*h; i++)
o[i] = 0;
// accumulate the points that fall inside the raster
for (int i = 0; i < n; i++)
{
int p = x[2*i+0];
int q = x[2*i+1];
if (p >= 0 && p < w && q >= 0 && q < h)
o[w*q+p] += 1;
}
}
#include <stdlib.h>
int main(void)
{
int w = 1000;
int h = 1000;
int n = 3000000;
float *x = malloc(2*n*sizeof*x);
float *o = malloc(w*h*sizeof*o);
for (int i = 0; i < 2*n; i++)
x[i] = 1000*(rand()/(1.0+RAND_MAX));
for (int i = 0; i < FPS ; i++)
plot_points(o, w, h, x, n);
return 0;
}
// NOTE: if this program runs in less than 1 second, it means that it
// is faster than "FPS"My earlier reply has a link to how GPUs actually push pixels to the screen.
There are also some excellent blog posts on how line rendering is done:
Then, to draw something like this imgur.com/a/mXvEBzl (ADS-B data, ~10 million points iirc), you need to connect points with (antialiased) lines, where individual pixel should be blended into plot with respect of line opacity. Also, lines can be of different thickness, so it multiplies your `o[w x p+p] += 1` again.
I'm not even talking about multiple layers that are quite standard.
I use my own plotting app, it takes a lot more than just slap a bunch of points into "float *o". Try to write your own, you will figure it out pretty quickly, unless you're ok with black blobs that resemble the input data.
> 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 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?
Now, besides this rant, I think that fastplotlib is fantastic and, as an (unwilling) user of Python for data science, it's a godsend. It's just that the hype of that website sits wrong in me. All the demos show things that could be done much easier and just as fast when I was a teenager. The big feat, and a really big one at that, is that you can access this sort of performance from python. I love it, in a way, because it makes my life easier now; but it feels like a self-inflicted problem was solved in a very roundabout way.