----- Mail original ----- > De: "Stefan Krah" <sk...@bytereef.org> > À: "numpy-discussion" <numpy-discussion@python.org> > Envoyé: Mardi 29 Avril 2025 12:09:26 > Objet: [Numpy-discussion] Re: Better compatibility of the Python > scientific/data stack with fast Python interpreters
> On Tue, Apr 29, 2025 at 11:20:28AM +0200, PIERRE AUGIER wrote: >> - slow as soon as the code involves Python extensions (because extensions >> work >> through an emulation layer, like cpyext in PyPy) > [...] >> Moreover, unfortunately, HPy does not currently receive as much care as it >> should. > > Does HPy solve the speed issue for C extensions? I thought it was more of a > compatibility layer so that things similar to CFFI could be used > automatically. > > CFFI/PyPy on the other hand was slower for the _decimal extension than > CPython. Yes, HPy does solve the speed issue for C extensions with PyPy and GraalPy. HPy can be seen as the native C API for PyPy and GraalPy, so that the emulation layer cpyext (https://pypy.org/posts/2018/09/inside-cpyext-why-emulating-cpython-c-8083064623681286567.html) can completely be avoided. With HPy you get typically the same speed for extensions than with CPython. Of course, the pure Python parts are much faster than with CPython, typically more than one order of magnitude faster for CPU bounded pure Python. Regarding C-extension speed, with HPy it could be possible to avoid boxing/unboxing (see for example https://github.com/hpyproject/hpy/issues/474), which could dramatically improve interaction between Python JIT and C code. Another huge advantage of HPy compared to the historical C API is that you can build "universal" wheels that can be used on all Python implementations and all Python versions. > CPython's C-extension speed is actually quite reasonable. The only garbage > collected language that achieves the _same_ extension speed that I know of > is OCaml (which is quite an achievement). Yes, but CPython is extremely slow on pure Python. And with objects fixed in memory and reference counting (or emulation of that), it's highly probable that it will stay very inefficient compared to alternative implementations and interpreters for comparable languages, for example JavaScript/TypeScript and Julia. > Does the Graal VM solve this issue? Yes, with Graal, the JIT can even act across the boundaries of languages. > > 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
