5 ms·

I guess what makes Python interesting right now is the integration with ML toolchains, CUDA, Metal/MLX, pytorch, tensorflow, LLM encoders/decoders, etc. more th

I guess what makes Python interesting right now is the integration with ML toolchains, CUDA, Metal/MLX, pytorch, tensorflow, LLM encoders/decoders, etc. more than Python the language. But can GraalVM run those codes meaningfully when Python is merely used for glue code with the important bits implemented in native code?

waldrews 2y ago
Looks like all of that would run in a native sandbox environment which in turn is called from the Python running on the JVM. So, maybe it simplifies interop, but whether it's straightforward to get full performance from the native layer (especially GPU/multicore) is an open question.
tln 2y ago
Yes, apparently it can https://www.graalvm.org/dev/reference-manual/python/Native-Extensions/ https://www.graalvm.org/dev/reference-manual/python/Native-E... > CPython provides a native extensions API for writing Python extensions in C/C++. GraalPy provides experimental support for this API, which allows many packages like NumPy and PyTorch to work well for many use cases. The support extends only to the API, not the binary interface (ABI), so extensions built for CPython are not binary compatible with GraalPy. Packages that use the native API must be built and installed with GraalPy, and the prebuilt wheels for CPython from pypi.org cannot be used. For best results, it is crucial that you only use the pip command that comes preinstalled in GraalPy virtualenvs to install packages. The version of pip shipped with GraalPy applies additional patches to packages upon installation to fix known compatibility issues and it is preconfigured to use an additional repository from graalvm.org where we publish a selection of prebuilt wheels for GraalPy. Please do not update pip or use alternative tools such as uv.
- theLiminator 2y ago
  I wonder if hpy will solve the extension problem.
  - RMPR 2y ago
    While hpy is great and I'm excited about it, I would rather bet on the limited C API[0] (which is basically what hpy tries to be if I understand correctly). 0: https://devguide.python.org/developer-workflow/c-api/#limited-api https://devguide.python.org/developer-workflow/c-api/#limite...
    - steve_s 2y ago
      Limited C API is not as abstract as HPy. Most notably Limited C API still exposes reference counting as memory management mechanism, HPy abstracts that. However, ecosystem wide adoption of limited C API and stable ABI would already improve things significantly.
  - mike_hearn 2y ago
    Yes, that's the idea.
- fniephaus 2y ago
  For anyone interested, here's the PyPI repository with additional binary wheels for GraalPy: https://www.graalvm.org/python/wheels/ https://www.graalvm.org/python/wheels/ We also want to make it easy for Python package maintainers to test and build wheels for GraalPy. It's already available via setup-python, and we are adding GraalPy support to cibuildwheel. If you need any help, please reach out to us!
yosefk 2y ago
The reasons for all this stuff having been developed in Python also make Python interesting right now, all by themselves. It did not happen by accident; this stuff was developed fairly recently and there was no shortage of mature languages to choose from.
- pjmlp 2y ago
  Using Python as C and C++ REPL of sorts has been common in academia since it took the scripting crown away from Perl and Tcl, which were used during the late 90's. Example see the Bioinformatics papers from that period, and the Perl tooling used alongside the research. Already in 2003 CERN was using Python on some of their build infrastructure (see CMT), Grid Computing scripting efforts, and we had Python trainings available to us. Now there is a difference between a REPL of sorts, scripting OS tasks, and going full blown applications with a pure interpreter.
- BiteCode_dev 2y ago
  The people disliking the language are very vocal about it, but there is a huge amount of silent people that loves it and an even bigger amount that just like it as much as alternatives. It's mainstream now, not trending like 10 years ago, so there is no hype about it anymore. We just use it to do stuff. Add to that the existing excellent ecosystem, the strong culture of scientific stacks and a very good story for providing c-extentions (actually the best one in all scripting languages because of things like cibuildwheel). It's only in small tech bubbles like HN that devs find it surprising.
  - lordgroff 2y ago
    I mean, even on HN, I'd say if there's derision, it's mostly one uttered with a yawn rather than genuine hate. And that's almost justified; while I spend a lot of my time with lots of different languages (I can't think of a single one I outright hate btw), Python is the one that pays for my things and... Well, there's not much drama there is there (now that we're lost 2->3 anyway)? It's a glue language that's easy to learn, but offers tons of depth should you want it. My primary annoyance at Python used to be the typing, but type annotations have made this less of an issue. It's a nice language and you can do almost everything with it. It's a bit boring, but I guess that's a good thing.
pjmlp 2y ago
I am willing to live with Python as the Lisp we deserve to have, on this AI wave, when it finally gets a proper JIT story we can rely on, regardless of the workload. Currently it is a mix and match of an herculean engineering effort mostly ignored by the community (PyPy), DSLs for GPGPUs, bunch of C and C++ libraries that people keep referring to as "Python" when any language can have similar bindings, jython, IronPython, GraalPy,... So it isn't for lack of trying, at least we finally have CPython folks more welcoming to performance improvements, and JITs.
- RMPR 2y ago
  > I am willing to live with Python as the Lisp we deserve to have You can have your cake and eat it too https://github.com/hylang/hy https://github.com/hylang/hy
- fastball 2y ago
  The problem with PyPy is that it doesn't support the C-API, which is required for all those other high performance libraries. So you gain the perf of a JIT, while losing out on most everything else high-performance in the Python ecosystem.
  - masklinn 2y ago
    Pypy has cpyext which implements a subset of the C-API, however it comes with a long list of caveats, and is more of a backstop, they very much prefer cffi.

waldrews 2y ago

Looks like all of that would run in a native sandbox environment which in turn is called from the Python running on the JVM. So, maybe it simplifies interop, but whether it's straightforward to get full performance from the native layer (especially GPU/multicore) is an open question.

tln 2y ago

Yes, apparently it can https://www.graalvm.org/dev/reference-manual/python/Native-Extensions/ https://www.graalvm.org/dev/reference-manual/python/Native-E... > CPython provides a native extensions API for writing Python extensions in C/C++. GraalPy provides experimental support for this API, which allows many packages like NumPy and PyTorch to work well for many use cases. The support extends only to the API, not the binary interface (ABI), so extensions built for CPython are not binary compatible with GraalPy. Packages that use the native API must be built and installed with GraalPy, and the prebuilt wheels for CPython from pypi.org cannot be used. For best results, it is crucial that you only use the pip command that comes preinstalled in GraalPy virtualenvs to install packages. The version of pip shipped with GraalPy applies additional patches to packages upon installation to fix known compatibility issues and it is preconfigured to use an additional repository from graalvm.org where we publish a selection of prebuilt wheels for GraalPy. Please do not update pip or use alternative tools such as uv.

theLiminator 2y ago
I wonder if hpy will solve the extension problem.
- RMPR 2y ago
  While hpy is great and I'm excited about it, I would rather bet on the limited C API[0] (which is basically what hpy tries to be if I understand correctly). 0: https://devguide.python.org/developer-workflow/c-api/#limited-api https://devguide.python.org/developer-workflow/c-api/#limite...
  - steve_s 2y ago
    Limited C API is not as abstract as HPy. Most notably Limited C API still exposes reference counting as memory management mechanism, HPy abstracts that. However, ecosystem wide adoption of limited C API and stable ABI would already improve things significantly.
- mike_hearn 2y ago
  Yes, that's the idea.
fniephaus 2y ago
For anyone interested, here's the PyPI repository with additional binary wheels for GraalPy: https://www.graalvm.org/python/wheels/ https://www.graalvm.org/python/wheels/ We also want to make it easy for Python package maintainers to test and build wheels for GraalPy. It's already available via setup-python, and we are adding GraalPy support to cibuildwheel. If you need any help, please reach out to us!

yosefk 2y ago

The reasons for all this stuff having been developed in Python also make Python interesting right now, all by themselves. It did not happen by accident; this stuff was developed fairly recently and there was no shortage of mature languages to choose from.

pjmlp 2y ago
Using Python as C and C++ REPL of sorts has been common in academia since it took the scripting crown away from Perl and Tcl, which were used during the late 90's. Example see the Bioinformatics papers from that period, and the Perl tooling used alongside the research. Already in 2003 CERN was using Python on some of their build infrastructure (see CMT), Grid Computing scripting efforts, and we had Python trainings available to us. Now there is a difference between a REPL of sorts, scripting OS tasks, and going full blown applications with a pure interpreter.
BiteCode_dev 2y ago
The people disliking the language are very vocal about it, but there is a huge amount of silent people that loves it and an even bigger amount that just like it as much as alternatives. It's mainstream now, not trending like 10 years ago, so there is no hype about it anymore. We just use it to do stuff. Add to that the existing excellent ecosystem, the strong culture of scientific stacks and a very good story for providing c-extentions (actually the best one in all scripting languages because of things like cibuildwheel). It's only in small tech bubbles like HN that devs find it surprising.
- lordgroff 2y ago
  I mean, even on HN, I'd say if there's derision, it's mostly one uttered with a yawn rather than genuine hate. And that's almost justified; while I spend a lot of my time with lots of different languages (I can't think of a single one I outright hate btw), Python is the one that pays for my things and... Well, there's not much drama there is there (now that we're lost 2->3 anyway)? It's a glue language that's easy to learn, but offers tons of depth should you want it. My primary annoyance at Python used to be the typing, but type annotations have made this less of an issue. It's a nice language and you can do almost everything with it. It's a bit boring, but I guess that's a good thing.

pjmlp 2y ago

I am willing to live with Python as the Lisp we deserve to have, on this AI wave, when it finally gets a proper JIT story we can rely on, regardless of the workload. Currently it is a mix and match of an herculean engineering effort mostly ignored by the community (PyPy), DSLs for GPGPUs, bunch of C and C++ libraries that people keep referring to as "Python" when any language can have similar bindings, jython, IronPython, GraalPy,... So it isn't for lack of trying, at least we finally have CPython folks more welcoming to performance improvements, and JITs.

RMPR 2y ago
> I am willing to live with Python as the Lisp we deserve to have You can have your cake and eat it too https://github.com/hylang/hy https://github.com/hylang/hy
fastball 2y ago
The problem with PyPy is that it doesn't support the C-API, which is required for all those other high performance libraries. So you gain the perf of a JIT, while losing out on most everything else high-performance in the Python ecosystem.
- masklinn 2y ago
  Pypy has cpyext which implements a subset of the C-API, however it comes with a long list of caveats, and is more of a backstop, they very much prefer cffi.