Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraalPy – A high-performance embeddable Python 3 runtime for Java

graalvm.org

Post reply on HN
Print view View original

111–120 of 151 posts

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#111

Post by hobofan »

andreldm wrote: post #29
nkzd wrote: post #20

What is the use-case for GraalPy? To be honest I don't understand why would anyone want to use it.

I worked at a company where data scientists wrote python code using pandas and we had port it to java and a library called keanu that was very useful but soon became unmaintained. Of course this was very time consuming and unrewarding, all because only java applications could be deployed to production due to a stupid top-down decision. This GraalPy sounds like something I wish existed back then.

jep[0] has existed for a while now, and does what GraalPy is doing quite well.

I'm using it for similar purposes as you stated and for that it works quite well. A research group I am collaborating with does a lot of their work in one Java application (ImageJ for microscopy), so by integrating my Python processing code into that application, it finds its way a lot quicker into the daily workflows of everyone in that group.

Most recently I've also extended the jep setup to include optional Python version bootstrapping via uv[1], so that I can be sure that the plugins I'm writing have the correct Python version available, without people having to install that manually on the machine.

[0]: https://github.com/ninia/jep

[1]: https://github.com/astral-sh/uv

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#112

Post by fniephaus »

tln wrote: post #15
tannhaeuser wrote: post #10

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?

Yes, apparently it can 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…

For anyone interested, here's the PyPI repository with additional binary wheels for GraalPy: 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!

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#113

Post by masklinn »

fastball wrote: post #100
pjmlp wrote: post #36

Earlier quoted context omitted.

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, IronPy…

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.

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.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#114

Post by jsmeaton »

Tried to use graalvm (interpreter) to run a fairly large project at my $dayjob$ and ran into a few issues right away.

  - Maturin doesn't support the graal interpreter, so no Py03 packages
  - uv doesn't seem to run, as `fork` and `execve` are missing from the os package?
  - Graal seems to have a huge number of patches to popular libraries so that they'll run, most seem to be of the form that patch c files to add additional IFDEFs
I don't think Graal is going to be a viable target for large projects with a huge set of dependencies unfortunately, as the risk of not being able to upgrade to different versions or add newer dependencies is going to be too high.

It's impressive what it does seem to support though, and probably worth looking at if you have a smaller scale project.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#115

Post by nomercy400 »

jsmeaton wrote: post #114

Tried to use graalvm (interpreter) to run a fairly large project at my $dayjob$ and ran into a few issues right away. - Maturin doesn't support the graal interpreter, so no Py03 packages - uv doesn't seem to run, as `fork` and `execve` are missing from the os package? - Graal seems to have a huge number of patches to popular libraries so that they'll run, most seem to be of the form that patch c files to add addition…

To be fair, this also happened when Graal was released for Java. Give it another go in 3-6 months, the Graal team will have improved interoperability massively.

It is a chicken (interpreter) and egg (dependencies) problem. You cannot fix the dependency problems without the interpreter. Neither can you release an interpreter with full dependency support.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#116

Post by sitkack »

jsmeaton wrote: post #114

Tried to use graalvm (interpreter) to run a fairly large project at my $dayjob$ and ran into a few issues right away. - Maturin doesn't support the graal interpreter, so no Py03 packages - uv doesn't seem to run, as `fork` and `execve` are missing from the os package? - Graal seems to have a huge number of patches to popular libraries so that they'll run, most seem to be of the form that patch c files to add addition…

For projects using GraalPy, I'd wager that most would vendor all their dependencies at the start of the project and upgrade along the way. I have shipped a couple products with Jython, and very little 3rd party code was used and almost none of the standard library, it was all driving Java from the same project.

So it does have to do with scale but in the opposite direction. Big long projects will want to adopt something like GraalPy because of how long the project will take.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#117

Post by mike_hearn »

theLiminator wrote: post #51
tln wrote: post #15

Earlier quoted context omitted.

Yes, apparently it can 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…

I wonder if hpy will solve the extension problem.

Yes, that's the idea.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#118

Post by mike_hearn »

theanonymousone wrote: post #107
theanonymousone wrote: post #11

Does it have to be run in a GraalVM, or any JVM implementation is fine?

Update. I actually managed to run the quick example with Temurin Java 22: java.vm.name=OpenJDK 64-Bit Server VM, java.vendor.version=Temurin-22.0.2+9

It won't JIT compile on anything other than GraalVM however. So it'll run, but slowly.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#119

Post by mike_hearn »

masklinn wrote: post #110
Rochus wrote: post #60

In case someone is interested, here are some benchmark results comparing GraalPy and others with JDK8 using the Are-we-fast-yet benchmark suite: https://stefan-marr.de/downloads/tmp/awfy-bun.html And here is a table representation of all benchmarks and the geomean and median overall results: http://software.rochus-keller.ch/awfy-bun-summary.ods The implementation of the same benchmark suite runs around factor 2.4 (ge…

Your mileage may very much vary, much like pypy this is very inconsistent and highly dependent on your workload (as well as your dependencies). My limited experience was that on re-heavy workload pypy is several times slower than cpython (~3x compared to 3.10) and graal is even worse (~6x compared to 3.11).

Which version was that with? GraalVM can JIT compile regular expressions these days, with the same compiler as everything else. They implemented TRegex on top of Truffle so regex can be inlined and optimized like regular code.

Performance does indeed depend on workload. There's a page that compares GraalPy vs CPython and Jython on the Python Performance Suite which aims to be "real world":

https://www.graalvm.org/latest/reference-manual/python/Perfo...

There the speedup is smaller, but this is partly because a lot of real world Python workloads these days spend all their time inside C or the GPU. Having a better implementation is still a good idea though, because it means more stuff can be done by researchers who don't know C++ well or at all. The point at which you're forced to get dedicated hackers involved to optimize gets pushed backwards if you can rely on a good JIT.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#120

Post by steve_s »

jsmeaton wrote: post #114

Tried to use graalvm (interpreter) to run a fairly large project at my $dayjob$ and ran into a few issues right away. - Maturin doesn't support the graal interpreter, so no Py03 packages - uv doesn't seem to run, as `fork` and `execve` are missing from the os package? - Graal seems to have a huge number of patches to popular libraries so that they'll run, most seem to be of the form that patch c files to add addition…

There is basic GraalPy support in Maturin[0] and PyO3[1], the problem is often that packages require older Maturin/PyO3 versions and/or they use CPython-isms, semi-public APIs, etc., but it is getting better, for example [2].

It is fair to say that large projects with a huge set of dependencies will likely face some compatibility issues, but we're working on ironing this out. There is GraalPy support in setup-python GitHub action. GraalPy is supported in the manylinux image [3]. Hopefully soon also in cibuildwheel [4].

[0] https://github.com/PyO3/maturin/pull/1645 (merged)

[1] https://github.com/PyO3/pyo3/pull/3247 (merged)

[2] https://github.com/pydantic/jiter/pull/135 (merged)

[3] https://github.com/pypa/manylinux/pull/1520 (merged)

[4] https://github.com/pypa/cibuildwheel/pull/1538

Post reply on HN