Performance is meaningless if the code is not correct.
After all, I can make the code arbitrarily fast if I'm not going to be held to any standard of correctness: It always returns "FOOBAR". Done, and very, very fast.
> Also: we chose C++, because it is fast.
That is a bit naive. C++ is a standard, so how fast is a stack of paper?
When your code is only fast because it does the wrong thing, and fixing the problem takes much more overhead.
Better, perhaps, if John Walker's experiences with Javascript are anything to go by:
https://www.fourmilab.ch/fbench/fbench.html
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.
Downloads: https://www.fourmilab.ch/fbench/
The weblog post where he analyzes the modern Javascript numbers a bit: https://www.fourmilab.ch/fourmilog/archives/2017-10/001715.h...
As-fast-as C when it is C (or Fortran or assembler…)
This is probably a better comparison: https://benchmarksgame-team.pages.debian.net/benchmarksgame/
Altough it seems to only have been run on node.js for Javascript.
(I happily and productively used C++ for many years; there's no hatred in the above sentiment.)
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?
I certainly wouldn't.
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.
Pypy etc never had the resources to build a truly amazing Python implementation. With Oracle throwing their weight behind Graal there's now ZipPy: http://thezhangwei.com/documents/oopsla113-zhang.pdf
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.
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.
No language implementation is "too slow" if performance doesn't matter.
> … Numpy is apparently not far of C in terms of performance
As-fast-as C when it is C (or Fortran or assembler…) :-)