Hacker News Reader

Comment by pjmlp | Hacker News Reader

Lisp, Smalltalk, Dylan, JavaScript prove otherwise regarding performance of dynamic languages.

The problem is that projects like PyPy remain on the sidelines, instead of being fully embraced by the community.

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.

C++ is pretty close to it.

C++ compilers can and do (g++, clang++) use pretty much the same set of optimization techniques used by C compilers.

And even offer REPL and Jupiter notebooks, so..

Which will never change, because instead of improving Python, one writes C instead.

I could even use them from TCL if bothered to do so, thus Python's benefits as programming language are meaningless.

Tensorflow has multiple language support for example.

> Python's benefits as programming language are meaningless.

Being the most flexible and user-friendly interface to the most powerful libraries written in other languages isn't meaningless.

That isn't unique to Python.

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.

There was no Web for pouring resources into Lisp, Scheme, Smalltalk, or even Dylan considering its short life.

Python already has it, PyPy, but it tends to be ignored by many.

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.

My point was about being fast enough, faster than CPython currently is by a factor of hundreds, not about beating C with its UB optimization tricks.

LuaJIT is stuck on a 2017 release, and an old Lua version, is it ever going to be updated?

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.

When those CPython applications are actually pure Python, without any call to C helper libraries.

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.

Reply on news.ycombinator.com