Hacker News
points by graemep 2 days ago | 0 comments
If you look at the reasons for this it seems like a good decision: https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to...

There are already many way of addressing Python performance (leaving aside whether Python is a good choice if performance matters) such as Cython, Numba, Pypy and C extensions.

[–] coldtea 2 days ago
>There are already many way of addressing Python performance (leaving aside whether Python is a good choice if performance matters) such as Cython, Numba, Pypy and C extensions.

And all of them are lacking in different ways, we ALSO, want faster pure Python.

[–] graemep 2 days ago
They all have drawbacks, but they also reduce the case for needing to speed up CPython.

Pypy does provide faster pure Python. Its a compatible implementation with JIT.

[–] thayne 2 days ago
The newest version of python that PyPy supports is 3.12. CPython is on 3.15.

And from what I understand there are limitations with using libraries that use the CPython API to interface with native code.

[–] coldtea 1 day ago
3.12 vs 3.15 would be fine, it's not like most depend on cutting edge features.

But the libraries limitations, and that it's not the "real" Python project, do get you.

[–] v3ss0n 2 days ago
Onlything is a lot of cextensions are super slow there. that is only bottleneck left which could be solved with resources that those guys spent on experimental jit.
[–] coldtea 1 day ago
Different guys. The CPython guys are not those behind Pypy. And they also don't want to see Pypy replace their project.
[–] cpburns2009 2 days ago
The problem with PyPy, which I'm a huge fan of BTW, is it's on life-support. The only reason the past couple major versions were released was due to a few small companies or individuals directly implementing the updates themselves. That's my understanding at least. It's disheartening because I've been primarily using PyPy for 5 years, advocated for it, and was looking into contributing more to it before finding out about its state.
[–] t43562 2 days ago
Perhaps if the money which was spent on the built-in JIT had been spent on PyPy we'd be somewhere.

PyPy wasn't great for me because its startup time interfered with the main usecase I wanted it for in one instance and in another there bugs that made it not quite compatible enough. Money could solve the bug issue.

On the other hand I did get pygame working with it at one point and that seemed like a nice scenario.

[–] xgk 1 day ago
PyPy's problem with slow startup is, in principle, easily fixable.

When it was created, PyPy did not seek to optimise startup performance. Instead, its aim was steady-state performance of JITed code, and it succeeded handsomely. A conceptually simple fix would be to optimise traces in one processor core, while the interpreter runs in another. Once when the trace is finalised, does interpretation stop and switch to native execution. But PyPy is currently a sequential system and making it parallel, while conceptually easy, is a lot of work and needs a rewrite of the whole system. But, for better or worse, the PyPy team does not have the resources to do this.

The other of PyPy's big performance issues (Python code using a lot of FFI calls via a suboptimal FFI) is also, in principle, easily fixable. But this is a social problem: the Python community would have to move towards better FFIs.

In principle, it would also be easy to fix PyPy's resource problem. I am not sure about the social problem ...

[–] t43562 1 day ago
At least CPython could agree to fix its FFI so that PyPy and others would have a chance.
[–] xgk 1 day ago
CPython could agree, and they have been asked to do so. But they refuse, because it would be a lot of work.
[–] cpburns2009 1 day ago
What would have been really nice is if the $1M/y in funding the PSF rejected due to ideological purity could have been reallocated to PyPy.