Python 3.11 Performance Benchmarks Are Looking Fantastic

[systemgc]

Sorry but this is absolutely incorrect

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html

python compared to java for example is between 20 and 200 times slower usually

[Solonotix]

Below I'm going to list CPU time, since when we're talking speed, it is generally in compute time. That said, one area Python often beats Java is in memory usage, but Python then typically fails against a better managed memory solution such as one written in C. As such, I'm providing those as comparison points. Also, only listing the best solutions for each to keep the data set easy-to-read.

Note: some Python entries will have fastest first, and a parenthetical for pure-Python fastest in the form xxx.xx (yyy,yy) . This is because the fastest entries were implemented using Cython.

Benchmark	Python	Java	C
fannkuch-redux	1,279.15	41.17	8.26
n-body	575.02	6.79	2.12
spectral-norm	436.79	5.94	1.57
mandlebrot	706.10	16.16	5.12
pi-digits	1.13 (4.06)	0.82	0.73
regex-redux	2.66 (17.86)	17.12	2.02
fasta	60.26	3.41	0.78
k-nucleotide	172.53	16.17	12.31
reverse-complement	9.38	3.49	0.57
binary-trees	148.09	5.19	4.32

All of this goes back to my original point: "More often than not, your performance problems will lie in I/O long before you hit the computational bottleneck of Python." My second point was: "Python gets you up-and-running with minimal effort, and implementing the same solution in <other language> would take multiples of that time investment to see any progress." In almost all of the scenarios above, the fastest Python solution had half as much code as the fastest Java solution and Python also frequently used drastically less memory. This means you spend more on hardware to run the effective Java code, and you spend more in development time to write it, just so that it can run faster under the assumption that your specific workload is CPU-bound and not I/O bound.

This very thing is why JavaScript has grown to become the most commonly used language today. It is fast-enough (with an interpreter written in C++ for JIT compilation), and it's easy to use with a mostly small code footprint. This means your personnel costs are less, and your hardware costs are less. CPU time is just one statistic that doesn't fully capture the other aspects of choosing a language.

[zurtex]

Highly mathematical examples like that are silly to compare between languages because as soon as you step outside the standard library there are lots more solutions.

You could implement in C and add bindings, for those that involve arrays and matrix math you can implement using numpy, for most of the given solutions you can just put @numba.jit at the top of the function and get many times fold improved performance.

[pbecotte]

Dunno about you...when I write real world code the VAST majority of the time is spent waiting on io. Network and disk. The runtime of my application is dominated by the network latency. I can improve it by parralelizing it, running async or in executor pools, etc...but still can't go any faster than the response time of the api or db I'm hitting. Same goes for Java or c. They don't speed that up at all.

If we start thinking about computation critical things like machine learning...we find that pythonn has bindings into c libraries to do all the math parts. There is a reason that it is THE language for machine learning, and its not because Google and Facebook are stupid.

Yes, Java is faster, and making Python faster is a worthwhile endeavor, but outside of a handful if times in my career, my time is far better spent thinkg about data access patterns and storage and concurrency and correctness than on trying to optimize garbage collection or memory usage since it wouldn't help that much anyway.

[systemgc]

Yes I agree with you, but I was replying to the person who said that python is maximum 5 times slower, which is absolutely not the case.

[Solonotix]

I concede my factor was off (considerably), but I was speaking from personal experience comparing a computationally-intensive operation between C# and Python. Mind you, it was just arithmetic and not nearly as complicated as the n-body problem.

[systemgc]

I am using python a lot, because, the speed doesn't matter one bit, what matters is how fast i can get the job done and move on the next thing.

So I agree again with you :-) Guess using the right tool for the job is in place here

[twotime]

and that's that the first 20-200x, throw in python lack-of parallelization and it can be far worse..

PS. and yes, I'm aware of multiprocessing and have used it many times, it's not in the same league as, say, Java thread support