C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.
No, It’s not possible to optimise Python like c++ because of the characteristics of the language.
Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.
Backwards compatibility with native extensions is the single biggest problem preventing optimising both Python and Ruby. If we could completely throw out C API compatibility like LuaJIT did, then we could make huge improvements to Python and Ruby performance and memory usage.
I have been using Python for a while now, and its rarely that the language is too slow (I have encountered it on one problem). A lot of Python is for web programming where you optimize the database and set up caching to improve performance. If you want to do some heavy number crunching Numpy is apparently not far of C in terms of performance.
Obviously its a case of the correct tool for the job and depends heavily on the type of software you are writing, but in most cases its a different type of optimization that is needed for Python code.
Consider the end to end performance of a system - from inputs in (say, timesheets and HR data) to outputs out (bank payment APIs called, emails sent).
Would you bet the end to end performance of a system built by mediocre C++ programmers would be better than that of a system built by mediocre Python programmers?
To elaborate a bit: what I mean is, it is easier to build an acceptably performant system in Python than in C++.
Yes, an arbitrary algorithm will probably perform significantly faster in C++.
But that probably won't matter in a real-world system built from multiple integrated components, when the performance is more likely to be determined by the abstractions chosen and the system architecture in use. And IMO Python and its surrounding ecosystem makes it easier to make good choices in those areas.
John Walker has a program called fbench which is a floating-point benchmark built around raytracing. He's implemented it many times, in many languages, throughout the decades, beginning with implementations for the original IBM PC.
Anyway, the results are posted on the site, in terms of multiples of the speed of the C implementation, which is defined to be 1.0. The Python implementation is 2.633 (PyPy 2.2.1 (Python 2.7.3), Linux), and the Javascript implementation is 0.372 (Mozilla Firefox 55.0.2, Linux). Yes, it completes in approximately a third the speed of a C implementation compiled on full optimization (-O3) by GCC 3.2.3.
(The C++ implementation is at 0.939, GCC 5.4.0 -O3.)
Anyway, Javascript has been the target of a lot of people for a fairly long time, and, despite the fact it's a very dynamic (hard-to-optimize) language... well, the numbers speak for themselves. I have no doubt Python could be improved to a similar degree.
Well the link you posted is not very useful - Javascript is faster on a trigonometry benchmark and the author admits it's probably because GCC's trigonometry functions are probably slow and not optimized. If you switch them out to use better functions or use a different compiler, I imagine the time would go down.
That is only a very specific benchmark and as that post said the result is so strange probably because of the changes in the C trigonometric functions lib that slowed down a lot to increase precision.
The point, however, is that if the difference is down to library code, the language itself isn't imposing a penalty. That is what is counter-intuitive here.
There's more to it than that. C++ is designed for implementations to produce fast code. "Leave no room between C++ and Assembly" has been a guiding principle of C++. This is not true of Python, and thus the engineering effort required for an implementation to reach the same level of performance is huge, if at all possible.
