It has been 2 months since a new version of Python 3.12 has been released. There are many syntax features added making the language more convenient to use. Though what about performance?
Not long ago I created a Mandelbrot set generator in 13 programming languages, Python included. Why not test the most recent version of the runtime? Mandelbrot generation is a CPU-bound benchmark that demonstrates how performant a given language is at executing lots of math computations in nested loops.
Here's the implementation I used, pure Python, no C++ dependencies involved (such as NumPy or Numba).
And here're the results from the MacBook Pro with M1 Pro (ARM CPU):
3.12.0 - ~45 sec
3.11.6 - ~41 sec
3.9.6 - ~67 sec
Dart VM - ~0.47 sec
gcc - ~0.25 sec
Added a few more contenders to the pack. Speaking of the 3.12 version, it is ~10% slower than 3.11, and the results are stably reproducible. Though both 3.12 and 3.11 are significantly faster than 3.9 that comes as standard on macOS.
VMWare, Ubuntu, Intel® Core™ i5-8257U CPU @ 1.40GHz × 2:
3.12.0 - ~54 sec
3.11.6 - ~54 sec
3.10.12 - ~85 sec
3.9.18 - ~85 sec
Dart VM - ~0.62 sec
gcc - ~0.33 sec
For comparison I have added results of Dart implementation (run in VM) and C++ (compiled via gcc) - we're talking of ~100x difference. This difference reminds of a rule of thumb that you should not do any loops, especially nested ones, with Python, and hand over this kind of workloads to C dependencies. Yet another confirmation of tradeoffs brought by Python - a super convenient glue language which is super slow in computation tasks.
P.S.: I have come across this more holistic comparison of 3.12 to 3.11. It had run pyperformance 1.0.9 on AMD Ryzen 9 7900 and Intel Core i3-1315U, both are x86 CPUs. What is curious is that on average 3.12 was ~10% slower on AMD while ~5% faster on Intel.
Top comments (6)
Спасибо. Как раз изучаю Dart - интересное сравнение.
Actually, that's an "unfair" comparison, as with GCC — Dart VM has a JIT compiler while CPython doesn't. Comparison with PyPy might be more illuminating.
Why is that unfair? And why PyPy out of hundreds of other runtime options available for Python? Cython? Maybe Numba? Why not go with Mojo right away, it is a superset of Python, right?
The comparisons is as fair as you get when you translate some piece of code 1-1 and get it compiled/run by some other PL/stack. If you have some generic implementation in pure Python vs same logic in Dart or JS - be ready to see 100x speedups. No one cares of other Python runtimes most of the time, CPython is the industry standard, and it is not just a language, it is the whole ecosystem.
P.S.: PyPy seems like a challenge to install on macOS via home-brew, for some reason it only has v 3.7 - that is the kind of typical situations with enthusiast projects that don't get even a fraction of attention as flagship projects.
I don't really understand your question for two reasons:
Because it has JIT compiler and supports almost all of CPython. At the very least it supports all pure Python without C extensions, thus it should run this particular benchmark with no issues.
They don't support full Python language, thus they are "unfair" too. It would be totally different comparison. The same is true for Mojo.
I can say the same about JS and even more so about Dart: you want to analyse data or train Deep NNs? Good luck with JS or Dart.
So if you invoke the argument that the runtime should be able to run arbitrary Python code (including C extensions) just like CPython does, then Dart and GCC become immediately irrelevant.
The trivial part that Dart and C are completely different languages (compiled vs interpreted) and hence saying it is "unfair" is a misleading statement adding little value to the discussion IMO.
It is what it is - same code in different languages and different runtimes. And it makes the point of performance levels of the most popular and used Python implementation
To me the phrase "the same code in different languages" makes no sense — if the languages are different, the code is different, and it exhibits different characteristics, including performance.
The fact that CPython is 100x or more slower than compiled and optimized C code is very old news and adds nothing to the discussion. :shrugging: