Hacker News Reader

Comment by Ralfp | Hacker News Reader

JIT is in weird place now because according to a recent talk from PyCON US by it’s author, the tier 2 optimizer that prepares code for JIT reduces performance by 20% and JIT just recovers that performance loss.

A lot of langugage is still not optimized by tier 2 [1] and even less has copy and patch templates for JIT. And JIT itself currently has some memory management issues to iron out.

[1]: https://github.com/python/cpython/issues/118093

Talk by Brandt Butcher was there but it was made private:

https://www.youtube.com/watch?v=wr0fVU3Ajwc

View on HN

I have seen some stuff about that, however that is to be expected.

Many of these kind of changes take time, and require multiple interactions.

See Go or .NET tooling bootstraping, all the years that took MaximeVM to evolve into GraalVM, Swift evolution versus Objective-C, Java/Kotlin AOT evolution story on Android, and so on.

If only people that really deeply care get to compile from source to try out the JIT and give feedback, it will have even less people trying it out than those that bother with PyPy.

> those that bother with PyPy

Which itself needed to be compiled from source the first time I tried it. All the hours of Mandelbrot were worth the spectacular speedup.

Which was a thing several years ago, not in 2024.

As mentioned I don't have any issues compiling it myself, more of an adoption kind of remark.

There are portable downloads of PyPy here https://pypy.org/download.html

It sounds like their point is that there's precedent for things in early stages only being provided as source, with binary releases coming later when things are more stable

On the other hand, if people who don't care enough to compile it for themselves try it out, the Python devs can be flooded with complaints and bug reports that effectively come down to it being in alpha.

You get both sides (yes, you might limit some who would otherwise try it out).

I think requiring people to compile to try out such a still-fraught, alpha-level feature isn't too onerous. (And that's only from official sources; third parties can offer compiled versions to their hearts' content!)

PyPy seems soo underrated....

So much work, and so little recognition :-/ I was looking forward to trying it out but moved off python before the libraries I used were compatible (sqlalchemy I believe was the one I was really wanting...)

PyPy still has GIL, though. In my practice (before I jumped ship to Go) PyPy never really made real code much faster. You still had to play games with shared memory to achieve multi-threading, and/or run multiple copies of a server process.

They should have just tried to go GIL-less instead of wasting time on trying transactional memory.

They did. They kicked off the STM project over a decade ago and produced a handful of releases. The project died on the vine:

> STM was a research project that proved that the idea is possible. However, the amount of user effort that is required to make programs run in a parallelizable way is significant, and we never managed to develop tools that would help in doing so. At the moment we're not sure if more work spent on tooling would improve the situation or if the whole idea is really doomed. The approach also ended up adding significant overhead on single threaded programs, so in the end it is very easy to make your programs slower. (We have some money left in the donation pot for STM which we are not using; according to the rules, we could declare the STM attempt failed and channel that money towards the present GIL removal proposal.)

https://pypy.org/posts/2017/08/lets-remove-global-interprete...

Reply on news.ycombinator.com