----- Mail original ----- > De: "matti picus via hpy-dev" <hpy-...@python.org> > À: "PyPy Developer Mailing List" <pypy-dev@python.org>, "Ralf Gommers" > <rgomm...@quansight.com>, "hpy-dev" > <hpy-...@python.org> > Envoyé: Vendredi 2 Mai 2025 10:05:51 > Objet: [hpy-dev] Re: [pypy-dev] Re: [Numpy-discussion] Better compatibility > of the Python scientific/data stack with > fast Python interpreters
> On Wed, Apr 30, 2025 at 3:30 PM Michał Górny <mgo...@gentoo.org> wrote: >> >> Hello, >> >> I'd like to just add a few data points from my Gentoo experience. >> ... >> I'm sorry but I don't understand what you're referring to. Sure, PyPy >> is not moving fast, but it definitely isn't dead. Sure, it sucks that >> we're still stuck in Python 3.11 era, but that doesn't make PyPy EOL. >> >> >> -- >> Best regards, >> Michał Górny >> > > It does not appear there will be a PyPy 3.12. When NumPy drops support > for Python3.11 (Jan 2026), future versions based on the CPython C-API > will defacto no longer be relevant for PyPy3.11. However, if HPy > succeeds, there is a chance that a NumPy "universal" HPy wheel will > still work on PyPy 3.11, as the API will be abstracted away from a > direct connection with the CPython C-API. This is one of the > attractions of HPy, that puts it in a different category than Cython > or nanobind: universal HPy binaries can run on any python interpreter > or version that supports the abstracted API. > > With the current level of active contributions to PyPy, I am not > convinced we can help making HPy a reality, even though it is a very > well thought out solution to once and for all detaching third party > libraries from a tight integration with the CPython C-API. I agree HPy > would be advantageous to both the CPython core team and package > maintainers. The yearly churn of packages needing to update for new > CPython C-API would be localized in the HPy layer for the new CPython > (similar to Cython, nanobind, and PyO3), and the CPython maintainers > would be free to change more aspects of the CPython internals that > unintentionally impact the external C-API (which differentiates HPy > from Cython, nanobind, and PyO3). But not all good ideas get to win > out and become the popular, goto solution. PyPy itself is an example > that, unfortunately. > Matti Hello, I'd like to try to work on this performance issue https://github.com/pypy/pypy/issues/5277. It is about the fact that allocations of types defined with HPy are very slow compared to the CPython counterpart (typically 7 times slower). I think it is a key problem when considering a potential revival of the HPy project with new funding (which would help PyPy). Some data in old messages seem to indicate that it is at least partly a regression: it seems that PyPy was in Sept. 2022 only something like 2 times slower. I guess fixing issue #5277 is very technical and I realize that I might not be able to be efficient on this subject. However, I'm motivated to learn and I can spend a bit of time and energy on this subject. So I'm asking for some kind of mentoring. Matti and Carl Friedrich, I would need your point of view on this project. Is it even possible to try to do something about #5277 for someone who has only a superficial knowledge of PyPy internals? Then, where and how to start? I guess the first thing to do would be to try to understand why PyPy is so slow by profiling (?), studying traces (?) and/or studying PyPy code, in particular the HPy implementation? I'd like to be clear that it is just a proposition and that I realize that I'm asking for your time. If you think that it does not make sense to try to work on this direction (#5277, HPy in general), please tell me! Pierre _______________________________________________ pypy-dev mailing list -- pypy-dev@python.org To unsubscribe send an email to pypy-dev-le...@python.org https://mail.python.org/mailman3//lists/pypy-dev.python.org Member address: arch...@mail-archive.com
