40 ms·

How fast does it have to be? I was curious and implemented a trivial loop in C++ that draws "scatter plot" on your benchmark (scatter plot with lots of [0,1]^2

How fast does it have to be? I was curious and implemented a trivial loop in C++ that draws "scatter plot" on your benchmark (scatter plot with lots of [0,1]^2 points). Its concept of "scatter plot" is: 1920x1080 image, draw a non-antialiased (i.e. ugly) filled blue circle of radius 4 at each point, where the unit square is stretched over the entire image. Doing this (C++, CPU) takes ~0.21 seconds for 2 million points, and ~2.06 seconds for 20 million points. The result is a solid blue rectangle, but that's beside the point. Doing the same on a trivial GPU implementation using CUDA, where I cheated by not even using atomic operations (so this only works because the dots are solid), takes ~0.23 seconds for 2 million points and ~2.3 seconds for 20 million points. Apparently the (my? (GTX 1050 mobile)) GPU doesn't help here. For comparison, with matplotlib (`plt.scatter(x, y); plt.show()`): for 2 million points, plt.scatter() takes ~10 seconds, and plt.show() takes about 3 seconds fill first image. Zooms/resizes etc. seem to be the same time, or if less points show, proportional to the number of visible points. So unsurprisingly my cheap C++ code is faster than matplotlib (it doesn't even anti-alias), but is it faster than Matlab? I have neither Octave nor Matlab, perhaps you can compare with matplotlib? EDIT: my code here https://gist.github.com/tomsmeding/1631090df10ab5ac98403304ec2b8ac9 https://gist.github.com/tomsmeding/1631090df10ab5ac98403304e...

ptero 6y ago
Thank you for the data point, but I do not think the issue is with rendering of the dots on screen (although I am not sure). In fact, I have done some real-time, frame-by-frame video processing using OpenCV and had no issue processing 1920x1080 images in real-time at 25fps (40ms per frame), including some simple edge detection, segmentation and rendering on screen using my office workstation. Modern hardware is certainly fast enough to render dots on the screen as fast as interactive processing needs. What I suspect is taking place with Octave/Python/Julia-based tools is the additional information that needs to be handled for each plot. You need to draw axes and ticks, keep tracks of which points are displayed and obscured at at the current axes limits and update all that information every time any of those things change (reset/move/zoom, etc.). It is certainly possible to make abstraction layers that are convenient for software engineers but would not scale well with respect to the number of points that need to be plotted. Or, instead of carefully tracking each state change one could regenerate a large portion of it to make it simpler (and slower). Just a guess though.
- tomsmeding 6y ago
  I do think it's plotting the points that is hard: note that what I'm measuring is not rendering the image on the screen, but creating the image of the dots in the first place. Creating the image is O(number of dots) work; displaying the image is O(number of pixels) work and GPU-accelerated and peanuts. I think this because in the end, after all the axis settings and such have been determined (and drawing the axes themselves is surely not the bottleneck), all that remains is just drawing the dots in the rectangular area set out for it. My benchmark does only that part, and as I said, I'm about 50x faster than matplotlib. (C++ and not Python, so I'm not picking on matplotlib, just observing.) But anyway, if this issue is to be solved it is to be done by contributing to Octave/matplotlib etc, not by throwing around proof-of-concepts on HN. :)

ptero 6y ago

Thank you for the data point, but I do not think the issue is with rendering of the dots on screen (although I am not sure). In fact, I have done some real-time, frame-by-frame video processing using OpenCV and had no issue processing 1920x1080 images in real-time at 25fps (40ms per frame), including some simple edge detection, segmentation and rendering on screen using my office workstation. Modern hardware is certainly fast enough to render dots on the screen as fast as interactive processing needs. What I suspect is taking place with Octave/Python/Julia-based tools is the additional information that needs to be handled for each plot. You need to draw axes and ticks, keep tracks of which points are displayed and obscured at at the current axes limits and update all that information every time any of those things change (reset/move/zoom, etc.). It is certainly possible to make abstraction layers that are convenient for software engineers but would not scale well with respect to the number of points that need to be plotted. Or, instead of carefully tracking each state change one could regenerate a large portion of it to make it simpler (and slower). Just a guess though.

tomsmeding 6y ago
I do think it's plotting the points that is hard: note that what I'm measuring is not rendering the image on the screen, but creating the image of the dots in the first place. Creating the image is O(number of dots) work; displaying the image is O(number of pixels) work and GPU-accelerated and peanuts. I think this because in the end, after all the axis settings and such have been determined (and drawing the axes themselves is surely not the bottleneck), all that remains is just drawing the dots in the rectangular area set out for it. My benchmark does only that part, and as I said, I'm about 50x faster than matplotlib. (C++ and not Python, so I'm not picking on matplotlib, just observing.) But anyway, if this issue is to be solved it is to be done by contributing to Octave/matplotlib etc, not by throwing around proof-of-concepts on HN. :)