Mailman 3 - hpy-dev - python.org

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

Re: [Numpy-discussion] Re: Better compatibility of the Python scientific/data stack with fast Python interpreters
by PIERRE AUGIER April 30, 2025

April 30, 2025

----- Mail original ----- > De: "Ralf Gommers via NumPy-Discussion" <numpy-discussion(a)python.org> > À: "Discussion of Numerical Python" <numpy-discussion(a)python.org> > Cc: "hpy-dev" <hpy-dev(a)python.org>, "pypy-dev" <pypy-dev(a)python.org>, "ralf gommers" <ralf.gommers(a)gmail.com> > Envoyé: Mercredi 30 Avril 2025 07:32:44 > Objet: [Numpy-discussion] Re: Better compatibility of the Python scientific/data stack with fast Python interpreters > On Tue, Apr 29, 2025 at 11:24 AM PIERRE AUGIER < [ > mailto:pierre.augier@univ-grenoble-alpes.fr | > pierre.augier(a)univ-grenoble-alpes.fr ] > wrote: > > > Dear Numpy community members and Numpy developers, > > This email is to get the points of view of the Numpy community members and > developers about a subject that I find very important. I'm going to introduce > it just in few lines so I write few statements without backing them with proper > arguments and without giving links and word definitions. I assume that most > people registered to the numpy-discussion list are at least familiar to the > subject. > > Thanks for thinking about this Pierre. > Thanks Ralf for your answer. Even if it is not very positive, it it VERY interesting! > I think getting proper compatibility of the Python scientific/data stack with > fast Python interpreters is very important for the long-term future of Python > for science and data. > > I'm not sure it is, it wouldn't rank high on my wish list. PyPy is nearing its > end-of-life, and GraalPy is really only for Java devs it seems - I've never > seen it in the real world. - PyPy and GraalPy are not used a lot because the Python ecosystem is highly incompatible with them since it is based on the CPython C API, which assumes in particular reference counting. This is really a chicken and egg problem. With a better ecosystem, we can anticipate a strong increase of PyPy and GraalPy usage. - I'm not aware that PyPy is nearing its end-of-life. It would really be a shame for Python to lose this project. - GraalPy is not at all only for Java devs. It can be used by every Python users. It is just a young project and its main issue for usability is the lack of specific wheels. Numpy implemented with HPy would fix that. However, Java devs can also be Python and Numpy users and getting Numpy fully compatible with GraalPy would be very good for applications using Java and Python. > With CPython performance being worked hard on, the performance gap is shrinking every year. I don't think the word "shrinking" is very adapted :-) ! Even on pyperformance (which is a set of benchmarks designed for CPython development), PyPy and GraalPy are still typically 4 to 5 times faster than CPython. For pure Python CPU bounded cases, it is more of the order of 20 times faster, which is typically comparable with what one gets with NodeJS. Unfortunately, the Faster CPython project is getting slowly and has a very hard time to get significant performance improvements. One can have a look at https://github.com/faster-cpython/benchmarking-public. It would be a great achievement if CPython 3.14 with its JIT can be 1.5 faster than CPython 3.10 (measured with pyperformance, again compared to typically 4 to 5 times faster with PyPy and GraalPy). The constrains on CPython (in particular related to the CPython C API) are so strong that for most cases the Faster CPython project won't be able to reach what can be obtained with fast Python implementations using advanced methods and algorithms. As long as the CPython C API assumes reference counting (and other implementation details bad for performance), CPython performance cannot reached what can be obtained with PyPy, GraalPy or NodeJS. If CPython changes too much its internals, it would need an emulation layer like PyPy's cpyext, and then extensions would become slower, which is of course not acceptable. > More importantly, none of these efforts (including the "faster CPython" > project), seem critical to numerical/scientific users. We're still talking > about pure Python code that gets maybe up to 5x faster, while the gains from > doing things in compiled languages are a lot higher. For numerical kernels, specialized static languages are clearly needed, but for global organisation and orchestration, PyPy and GraalPy are really very efficient (I guess in most cases efficient enough). For pure Python code and compared to CPython, the factor is not 5x but more 10x or 20x. > So the benefits are more > important for small packages if it moves the threshold at which it becomes > necessary for them to write zero extension modules. For core libraries like > NumPy, pure Python performance isn't super critical. For libraries like NumPy, it is not. But for users of these libraries, it is. Or at least getting the possibility to use fast Python (typically as fast as Javascript) would change what we can do with Python and what can be coded in Python. For example, currently, it is not doable to use a lot of small Python objects in performance critical code so nice OOP Python cannot be used. With alternative fast Python implementations more usable with an ecosystem using HPy and universal wheels, it would become possible. I remember during a Python training a person (it was a good C++ developer) trying to write something doing ray tracing with OOP and Numpy. It was super slow with CPython so I told him to try in pure Python with PyPy (it was just a game to learn so why not). He soon got a prototype and was quite impressed with the speed. Then there was something else in the code that was convenient to be done with Numpy and then, pff, all the good performance disappeared because the Numpy calls where super slow (going through cpyext) and the rest of the code was then using some Numpy numbers. This was very frustrating. We also see projects using a lot Python (with lot of small objects) that are so slow compared to comparable alternatives (for example Pelican compared to Hugo in Go; myst-parser compared to mystmd in JavaScript; I also think about Sphinx and its so long builds, ...). It would change the life of Python users if it would be easy to use fast implementations with performance similar to NodeJS. Moreover, if boxing/unboxing can be avoided between Python JITs and native code (which should be doable with HPy), Numpy calls would be significantly faster. With Graal VM it could even be more spectacular because it could be possible that the same JIT compiles together Python and native code without barriers across the language boundaries. > When thinking about overall performance improvements, I'd say that the two most > promising large developments are: (1) making it easier to use accelerator > libraries (PyTorch, CuPy et al.), and (2) free-threaded CPython for enabling > Python-level threading. Good and usable sub-interpreters would also be great and I think this is highly coupled with Numpy-HPy. > [...] > > Moreover, unfortunately, HPy does not currently receive as much care as it > should. > > > > It seems to me that the project of fixing the roots of the Python ecosystem has > to be relaunched. I think that the dynamics has to come from the Python > scientific/data community and in particular Numpy. It is unfortunately outside > of the C API working group's scope (see [ > https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c… > | > https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c… > ] ). > > It seems to me that it is necessary (and possible) to get some founding for such > an impactful project so that we can get people working on it. > > I'd like to write a long and serious text on this subject, and I first try to > get the points of view of the different people and projects involved. > > I guess I should write explicit questions: > > - What do you think about the project of fixing the Python scientific/data stack > so that it becomes natively compatible (hence fast and convenient, with easy > installations) with alternative and fast Python interpreters? > - Do you have points of view on how this should be done, technically (HPy?, > something else?) and on other aspects (community, NEP?, founding, ...). > - Anything else interesting on this subject? > > Having HPy or something like it will be very nice and lead to long-term > benefits. The problem with HPy seems to be more a social one at this point: if > CPython core devs don't want to adopt it but do their own "make the C API more > opaque" strategy, then more effort on HPy isn't going to help. If you're going > to dig into this more, I suggest trying to get a very good sense of what the > CPython core dev team, and in particular its C API Workgroup, is > thinking/planning. That will inform whether the right strategy is to help their > efforts along, or work on HPy. This is very interesting that you write that! This is exactly what I tried to understand with my questions in https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c… I think that the discussion was very informative. It is in particular interesting to see that the C API working group is only focused (i) on the "historical" CPython C API (HPy is considered as an external project) and (ii) on slow and gradual evolution of this C API (to go at the pace of the slowest projects using the CPython C API). Some CPython core devs work in the direction of "making the C API more opaque", but important "revolutionary" changes (like providing an API not assuming reference counting) have just been discussed (https://github.com/capi-workgroup/api-revolution/issues) and it seems that there are not yet practical plans for them (for example https://github.com/markshannon/New-C-API-for-Python/ is stopped). Moreover, there are no time schedule and there cannot be any time schedule since the pace depends on all CPython C API users. In practice, to get in a reasonable time (not 12 years) the scientific/data Python stack natively compatible with advanced methods used in dynamic language interpreters, one needs (i) to invest on HPy and (ii) to port Numpy to something else than the CPython C API (it can be HPy but it could also be Cython or maybe other things). Also, it seems that the C API working group does not care about the principle of the HPy universal wheels (compatible across Python versions and implementations). To have something like that, we need HPy. It seems to me that a strategy based on HPy would give practical benefices for users in a much shorter time (typically few years) than just waiting for CPython C API evolution. Let's recall that Numpy 1 has already been ported in HPy (like Matplotlib by the way). I thus agree with > The problem with HPy seems to be more a social one at this point Cheers, Pierre

1 0

Better compatibility of the Python scientific/data stack with fast Python interpreters
by PIERRE AUGIER April 29, 2025

April 29, 2025

Dear Numpy community members and Numpy developers, This email is to get the points of view of the Numpy community members and developers about a subject that I find very important. I'm going to introduce it just in few lines so I write few statements without backing them with proper arguments and without giving links and word definitions. I assume that most people registered to the numpy-discussion list are at least familiar to the subject. I think getting proper compatibility of the Python scientific/data stack with fast Python interpreters is very important for the long-term future of Python for science and data. Nowadays, fast Python implementations like PyPy and GraalPy are - complicated to use (need local builds of wheels) - slow as soon as the code involves Python extensions (because extensions work through an emulation layer, like cpyext in PyPy) Therefore, these fast Python implementations are not as popular as they should be. However, they are really great tools which should be used in particular for scientific/data applications. Unfortunately, if we just follow the pace of the CPython C API evolution, we will basically never have an ecosystem natively compatible with fast Python implementations. The more I think and learn about this subject, the more I think that Numpy has to stop using directly the CPython C API and to be ported to HPy (though there are other alternatives - in particular Nanobind and Cython - that could be discussed). Numpy 1 has been ported to HPy but unfortunately, there have been deep changes with Numpy 2 (and Meson) so it seems that one should restart the porting. Moreover, unfortunately, HPy does not currently receive as much care as it should. It seems to me that the project of fixing the roots of the Python ecosystem has to be relaunched. I think that the dynamics has to come from the Python scientific/data community and in particular Numpy. It is unfortunately outside of the C API working group's scope (see https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c…). It seems to me that it is necessary (and possible) to get some founding for such an impactful project so that we can get people working on it. I'd like to write a long and serious text on this subject, and I first try to get the points of view of the different people and projects involved. I guess I should write explicit questions: - What do you think about the project of fixing the Python scientific/data stack so that it becomes natively compatible (hence fast and convenient, with easy installations) with alternative and fast Python interpreters? - Do you have points of view on how this should be done, technically (HPy?, something else?) and on other aspects (community, NEP?, founding, ...). - Anything else interesting on this subject? Best regards, Pierre -- Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels BP53, 38041 Grenoble Cedex, France tel:+33.4.56.52.86.16

1 0

FYI: question related to HPy on discuss.python.org
by PIERRE AUGIER April 28, 2025

April 28, 2025

FYI, I asked a question related to HPy on discuss.python.org and got interesting answers from CPython core devs: https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c…

1 1

Future of HPy? Faster CPython, and comparison between different Python interpreters
by PIERRE AUGIER Nov. 19, 2024

Nov. 19, 2024

Hi HPy developers, I send this email here since it can reach people interested in HPy, and PyPy/GraalPy developers. CPython 3.13 has an experimental JIT. The results in term of global performance can be followed here https://github.com/faster-cpython/benchmarking-public. It is still very modest (best results are something like 1.4 time faster than CPython 3.10). However, there are other plans to improve CPython new JIT (https://github.com/faster-cpython/ideas/blob/main/3.14/README.md, see also https://github.com/faster-cpython/ideas/issues/701#issuecomment-2405979384) so we can guess that CPython 3.14 and 3.15 will be (a bit?) faster. In https://github.com/faster-cpython/ideas/blob/main/3.14/README.md, I read with interest that HPy is mentioned! #### HPy-like C API Tagged integers will require new internal APIs to pass opaque references, so we might as well add a new, consistent API modeled on [HPy](https://hpyproject.org/). We will use this internally to start with, but we expect tools like [Cython](https://cython.org/) and [Pybind11](https://github.com/pybind/pybind11) will want to use it to avoid the overhead of going through the `PyObject *` based API. So I was wondering about the state of HPy. For example, is there a plan to port Numpy 2 in HPy? What about HPy support in Cython? Do you still think HPy could become more popular and used? Another related question is about the performance comparison between different interpreters. It seems to me that the difference of performance between CPython and other alternative interpreters is a strong argument for HPy. Seeing the performance comparisons with different versions and commits of CPython, I was wondering about similar comparisons with other interpreters (in practice PyPy and GraalPy). It would be very interesting to know from fair benchmarks about the performance of different interpreters. In https://github.com/oracle/graalpython, it's written "GraalPy is ~4x faster than CPython on the [official Python Performance Benchmark Suite](https://pyperformance.readthedocs.io/)". In https://pypy.org/, there is written "PyPy is 4.4 times faster than CPython 3.7", but comparing to CPython 3.7 does not make sense nowadays. Is it also measured with https://pyperformance.readthedocs.io/ ? Do you think it would be interesting and feasible to have a website showing fair comparisons between different Python interpreters ? I guess a simple solution would be to use faster-cpython workflows by asking them to also consider stable releases of PyPy and GraalPy. I'm going to ask in https://github.com/faster-cpython/ideas. Would there be a good alternative solution to get such data? Pierre Augier

2 2

Re: hpy-dev Digest, Vol 45, Issue 1
by da-woods Nov. 16, 2024

Nov. 16, 2024

Just to answer one of your questions: Cython and HPy. The answer is "not yet". I know Du Toit Spies has made some initial progress on it working with the GraalPython people. That's available at https://github.com/DuToitSpies/cython. I did meet him at EuroPython this year and made some rash promises about trying to get it merged into Cython proper. Time and other distractions have got in the way, although it's something I do still intend to do. David On 15/11/2024 17:00, hpy-dev-request(a)python.org wrote: > Send hpy-dev mailing list submissions to > hpy-dev(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman3/lists/hpy-dev.python.org/ > or, via email, send a message with subject or body 'help' to > hpy-dev-request(a)python.org > > You can reach the person managing the list at > hpy-dev-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of hpy-dev digest..." > > Today's Topics: > > 1. Future of HPy? Faster CPython, and comparison between different Python interpreters > (PIERRE AUGIER) > > _______________________________________________ > hpy-dev mailing list -- hpy-dev(a)python.org > To unsubscribe send an email to hpy-dev-leave(a)python.org > https://mail.python.org/mailman3/lists/hpy-dev.python.org/

1 0

PiterPy 2024 Invitation
by Sergei Iakhnitskii May 8, 2024

May 8, 2024

Dear HPy developers, I’m Sergei Iakhnitskii, a PiterPy Conference program committee member. I once did a talk about major changes in Python 3.8-3.11 and noticed how crucial C API and internal work (PEPs 573, 579, 630, 687 and so on) were on the whole Python ecosystem. The talk about HPy on the Language Summit brought a novel approach to the existing problem. https://pyfound.blogspot.com/2023/05/the-python-language-summit-2023-three.… We organize the PiterPy conference, which focuses on Core Python, Libraries and Tools, Development Practices and more. Here’s the link: https://piterpy.com/en/ Our community appreciates your work on C-API and Cython and they’ll be thrilled if you could give a talk on it. So, I invite you to speak at PiterPy! A few details about the conference: September 18 - online, September 26-27 - offline; It means that you can choose the way you would like to perform: remote, studio in Saint Petersburg or offline at the venue (Saint Petersburg); Audience: 500 attendees (programmers, engineers, architects, and others). We would really appreciate it if you join us. It may be any format you want to choose: a talk, a workshop, a podcast-like Q&A session, or a panel discussion. Please let me know what you think, or directly submit a talk: https://piterpy.com/en/callforpapers/. Looking forward to hearing your answer regardless of your decision. If you have any questions, please let me know. Kind regards, Sergei Iakhnitskii

1 0

Reminder: HPy dev monthly call
by Florian Angerer March 6, 2024

March 6, 2024

Hi, the next HPy call is scheduled for this Thursday (March 7th at 10am CET / 9am UTC). ATTENTION: time changed again. Single click URL to join Zoom: https://oracle.zoom.us/j/339127822?pwd=YkNZbFgvdXZ4Z3NlcWg1N3BlZ3JTUT09 Meeting ID: 339 127 822 Password: 237729 Regards, Florian

1 0

Reminder: HPy dev monthly call
by Florian Angerer Jan. 31, 2024

Jan. 31, 2024

Hi, the next HPy call is scheduled for this Thursday (February 1st at 4pm CET / 10am EST / 3pm UTC). ATTENTION: time changed. Single click URL to join Zoom: https://oracle.zoom.us/j/339127822?pwd=YkNZbFgvdXZ4Z3NlcWg1N3BlZ3JTUT09 Meeting ID: 339 127 822 Password: 237729 Regards, Florian

1 0