7 ms·

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 b

by Ralfp 2y ago

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 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 https://www.youtube.com/watch?v=wr0fVU3Ajwc

pjmlp 2y ago
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.
- sevensor 2y ago
  > 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.
  - pjmlp 2y ago
    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.
  - mattip 2y ago
    There are portable downloads of PyPy here https://pypy.org/download.html https://pypy.org/download.html
    - saghm 2y ago
      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
- targafarian 2y ago
  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!)
- mech422 2y ago
  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...)
  - cyberax 2y ago
    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.
    - bastawhiz 2y ago
      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-interpreter-lock-748023554216649595.html https://pypy.org/posts/2017/08/lets-remove-global-interprete...
dangitman 2y ago
[dead]

by Ralfp 2y ago

pjmlp 2y ago

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.

sevensor 2y ago
> 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.
- pjmlp 2y ago
  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.
- mattip 2y ago
  There are portable downloads of PyPy here https://pypy.org/download.html https://pypy.org/download.html
  - saghm 2y ago
    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
targafarian 2y ago
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!)
mech422 2y ago
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...)
- cyberax 2y ago
  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.
  - bastawhiz 2y ago
    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-interpreter-lock-748023554216649595.html https://pypy.org/posts/2017/08/lets-remove-global-interprete...

dangitman 2y ago

[dead]