> I like to define my subroutines using a modern language like C++, which goes 47 gigaflops. This means C++ is three orders of a magnitude faster than Python. That's twenty years of progress per Moore's law.
This is great. I love the idea of measuring performance differences in “years of Moore’s law.”
Twenty years puts the delta in an easy to understand framework.
Python on 2024 hardware vs C++ on 2004 hardware ... I don't think it's obvious that C++ always wins here, though it would depend on the use case, how much of the Python is underpinned by native libraries, and the specific hardware in question.
You can't not include native libraries, at least if you want your benchmark to be realistic. Almost every Python library where performance matters is written (at least partially) in a compiled language.
Yes, but many people like the sound of "X-times faster than Python" while conveniently forgetting that the same thing can be (and usually is) done in Python + numpy & co. even faster.
I have come to appreciate "slowness" of Python. It trades speed for legibility, which is a great compromise once you have really fast native libraries one import away. Best of both worlds.
C++ with well-optimized libraries should always outperform Python with well-optimized libraries, right? They should be ~identical in the highly optimized inner loops, but Python has more overhead. But naive hand-written C++ could easily perform worse than something like Numpy.
(I've only tested this once, and my naive hand-written C++ was still twice as fast as Numpy, but that was only on one specific task.)
This is great. I love the idea of measuring performance differences in “years of Moore’s law.”
Twenty years puts the delta in an easy to understand framework.