[Numpy-discussion] Re: [hpy-dev] Re: [pypy-dev] Re: Better compatibility of the Python scientific/data stack with fast Python interpreters
Thanks Matti for this interesting and sad piece of news. I also reply on numpy-discussion@python.org since your message was not post on this list and take the opportunity to signal another important post about his subject on discuss.python.org by Stepan Sindelar: https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c-api-compatible-with-alternative-python-implementations/89477/19 IMHO, anyone interested in the long term future of Python should be aware of these issues. Pierre - Mail original - > De: "matti picus via hpy-dev" > À: "PyPy Developer Mailing List" , "Ralf Gommers" > , "hpy-dev" > > 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 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 > ___ > hpy-dev mailing list -- hpy-...@python.org > To unsubscribe send an email to hpy-dev-le...@python.org > https://mail.python.org/mailman3/lists/hpy-dev.python.org/ > Member address: pierre.aug...@univ-grenoble-alpes.fr ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Better compatibility of the Python scientific/data stack with fast Python interpreters
- Mail original - > De: "Stefan Krah" > À: "numpy-discussion" > Envoyé: Mercredi 7 Mai 2025 13:47:19 > Objet: [Numpy-discussion] Re: Better compatibility of the Python > scientific/data stack with fast Python interpreters > On Wed, Apr 30, 2025 at 02:08:36PM +0200, PIERRE AUGIER wrote: >> 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. > > It would be nice to use alternative interpreters, but I still see conflicting > messages about the performance of HPy: > > https://github.com/psycopg/psycopg/issues/154 > > "If the goal is to run psycopg3 fast in PyPy, there are at least three paths: > >use a cffi backend: this is likely to be the fastest one >(in case psycopg uses Cython and doesn't call directly any CPython C API): > use >the Cython HPy backend, once it's ready >(in case psycopg uses the CPython C API directly): rewrite it to use HPy >instead." One can create from a C file using the HPy API a standard Python extension using in the background the CPython C API. So for CPython, there should be no performance penalty. Numpy-HPy should be on CPython as fast as current Numpy. From the same file, one can also create a universal extension that can be used on different Python implementations (and for different Python versions). On CPython, there is a relatively small performance penalty (few percents). On PyPy and GraalPy, the calls are basically as fast as on CPython with the standard Python extension. Then, there can be other performance improvements with other methods, some already possible (in particular on GraalPy) and some that would need further HPy developments (avoiding boxing/unboxing). > CFFI however is slower, e.g. for _decimal, than the native CPython C-API. > (At least it was in version 3.9, _decimal has been slowed down significantly > since I left.) Could you explain a bit more? Or provide a link? CFFI with PyPy? or CFFI with CPython? Is there a proper reproducible benchmark? > _decimal of course operates on scalars and has many API calls, so maybe > for NumPy this is not relevant except for small arrays. Yes, for most real world code using Numpy, the performance of the interface is not crucial for the overall program performance. It is just important to avoid very inefficient things, like the emulation layers needed with the CPython C API (like PyPy cpyext). > Or perhaps HPy has evolved in the meantime (the above GitHub thread is from > 2022). > > > Stefan Krah > > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: pierre.aug...@univ-grenoble-alpes.fr ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Better compatibility of the Python scientific/data stack with fast Python interpreters
- Mail original - > De: "Stefan Krah" > À: "numpy-discussion" > Envoyé: Mercredi 7 Mai 2025 18:17:38 > Objet: [Numpy-discussion] Re: Better compatibility of the Python > scientific/data stack with fast Python interpreters > On Wed, May 07, 2025 at 03:52:33PM +0200, PIERRE AUGIER via NumPy-Discussion > wrote: >> > "If the goal is to run psycopg3 fast in PyPy, there are at least three >> > paths: >> > >> >use a cffi backend: this is likely to be the fastest one >> >(in case psycopg uses Cython and doesn't call directly any CPython C >> > API): use >> >the Cython HPy backend, once it's ready >> >(in case psycopg uses the CPython C API directly): rewrite it to use HPy >> >instead." > [cut] > >> Could you explain a bit more? Or provide a link? CFFI with PyPy? or CFFI with >> CPython? > > Yes: _if_ the above 2022 quote from the psycopg3 issue is still valid, > and my benchmarks show that the CPython C-API is faster than the PyPy > CFFI, then (according to the quote), HPy is slower than PyPy CFFI and > therefore much slower than CPython C-API. > > All of that under the assumption that there are many API calls. > >> Is there a proper reproducible benchmark? > > Here are the benchmarks for _decimal: > > bench.py > [...] Interesting thinking and benchmarks. I don't think PyPy CFFI should be faster than HPy, at least theoretically and when the implementations of the HPy ABI in PyPy and GraalPy will be more ready in terms of performance. The promisse of HPy is that you don't get performance regression with CPython AND you get something really efficient on alternative implementations. To check that, I worked a bit on benchmarks (Piconumpy benchmarks and HPy microbenchmarks). Unfortunately, we are still not yet there and the implementations of HPy ABI in PyPy has yet few performance issues, in particular related to object creations/deletions. I can share these results which are quite understandable and interesting: == PyPy HPy univ / CPy native (time ratio, smaller is better) == TestModule::test_noargs 0.50 TestModule::test_onearg_None 0.60 TestModule::test_onearg_int 0.65 TestModule::test_varargs 0.93 TestModule::test_call_with_tuple 2.21 TestModule::test_call_with_tuple_and_dict 1.50 TestModule::test_allocate_int 0.67 TestModule::test_allocate_tuple 6.33 TestType::test_allocate_obj 5.89 TestType::test_method_lookup 0.05 TestType::test_noargs 0.85 TestType::test_onearg_None0.95 TestType::test_onearg_int 0.97 TestType::test_varargs1.18 TestType::test_len0.48 TestType::test_getitem0.73 TestHeapType::test_allocate_obj_and_survive 5.11 TestHeapType::test_allocate_obj_and_die 4.07 TestHeapType::test_method_lookup 0.05 TestHeapType::test_noargs 0.84 TestHeapType::test_onearg_None0.93 TestHeapType::test_onearg_int 0.96 TestHeapType::test_varargs1.20 TestHeapType::test_len0.50 TestHeapType::test_getitem0.78 Here we compare the time obtained with PyPy with a HPy universal extension (written with the HPy API) to the time obtained with CPython (3.12) with a standard extension (written with the CPython C API). Interestingly, most cases are fine, with values smaller than 1, meaning that PyPy is faster than what is currently obtained with CPython. This is remarkable because it is about interacting with a C extension, with nothing in pure Python! Unfortunately, there are also few important cases (mostly related to "allocate_obj") which are much slower than CPython (of the order of 5 times slower!). I don't know if PyPy can improve or fix this known problem. Let's stress that these are microbenchmarks focusing on the C API. The numbers would not be the same on real life code and they would of course strongly depend on the time spent in Python and in native code. The result of a HPy transition of the ecosystem would not (yet*) be to strongly accelerate code using small objects of types defined in C extensions. It would be that it would be more possible to code more things in pure Python and to mix pure Python and native extensions, for exemple objects of Python defined classes with Numpy arrays attributes. PyPy has this very nice property that Python abstractions can be used "for free" (without any cost in terms of performance). * "yet" because there are
