hpy-dev

Download

[email protected]

May 2025

3 participants
2 discussions

Question about ref counting and non-movable objects
by PIERRE AUGIER May 5, 2025

May 5, 2025

Hi, I try to write a text about what I understood on problems related to the CPython C API, CPython performance, the scientific Python ecosystem and HPy (see https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c… and recent mails in this list). I have a specific question about the effect of ref counting and non-movable objects for interpreters of dynamic languages like Python. Since all fast Python interpreters (and many interpreters for other similar languages) use more complex alternatives, I guess this would be very difficult to get good performance with such methods. However, I don't really know why and if it could be possible to get good performance with such algorithms. Interestingly, the Faster CPython project tries to make CPython faster while keeping ref counting and non-movable objects. I guess people knowing the subject (for example PyPy or GraalPy devs) could give good arguments on these questions or provide interesting and serious references. Best regards, Pierre

2 1

Re: [pypy-dev] Re: [Numpy-discussion] Better compatibility of the Python scientific/data stack with fast Python interpreters
by matti picus May 5, 2025

May 5, 2025

On Wed, Apr 30, 2025 at 3:30 PM Michał Górny <mgorny(a)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

2 1