That's because PyPy has poor support for C-API exentions, which is what all the performance-oriented python packages rely on.
Most people doing serious numeric work don't care about the speed of the Python interpreter because all the heavy lifting is done by optimized libraries like Numpy and TensorFlow.
Then maybe the statement should have been "I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like dropping the legacy C interface to Python objects."
The fastest dynamic languages I see are those which have no C interface at all. How many of the performance optimizations in a modern JavaScript engine would be possible if it had to support accessing every property of every object as a C string at any point in a program? JS has exactly none of the features that comment claims would be necessary for performance.
> dropping the legacy C interface to Python objects.
This is nonsense. No language ever will have linear algebra or numeric implementations faster than Fortran/C implementations of BLAS, LAPACK etc. Not being able to make ffi calls makes python essentially unusable for most of its niche uses.
> JS has exactly none of the features that comment claims would be necessary for performance.
I don't see people doing ML, scientific computing etc in JS.
You're confusing "no FFI whatsoever" with "a sane FFI". Python's legacy interface is insane--it exposes virtually all details of the CPython interpreter to C extensions such that any deviation from CPython's implementation is effectively a breaking change.
Because of the web, Google and other companies have poured tons of resources into improving the speed of JavaScript. I wonder where Python would be if the same level of resources had been devoted to it.
Interestingly you didn't mention Lua. The best Common Lisp, Smalltalk, and JS systems are always about a factor of 2 to 10 slower than C. This is not very good evidence for your assertion. (I suspect that's true of Dylan too, but haven't tried it.) By contrast, LuaJIT often beats GCC on performance. This is excellent evidence for your assertion.
Typically I measure CPython at about 40× slower than C, and SBCL, V8, and the like at about 2–10× slower than C. What cases are you seeing where those runtimes are hundreds of times faster than CPython?
People don't normally update to new versions of Lua, because they're not backwards compatible; it's not like Python or JS. WoW is still using Lua 5.1, as is MediaWiki. It's unlikely that this will ever change.
Probably at some point someone will continue LuaJIT development. It seems as likely that they will diverge in a different direction as follow PUC.
Right! When your hot code is in C you get a performance mix. Still, only about 3% of your logic has to be in interpreted Python for it to dominate your runtime.
The problem is that projects like PyPy remain on the sidelines, instead of being fully embraced by the community.