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

11–20 of 151 posts

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

#12

Post by westurner »

lopuhin wrote: post #8
pjmlp wrote: post #4

Earlier quoted context omitted.

Python implementations naturally don't have any GIL in regards to JVM or CLR variants, there is no such thing on those platforms. YAML and JSON have both tried to replicate the XML tooling experience, only worse. Schemas, comments, parsing and schema conversions tools.

I think GraalPython does have a GIL, see https://github.com/oracle/graalpython/blob/master/docs/contr... - and if by "there is no such thing on those platforms" you mean JVM/CLR not having a GIL, C also does not have a GIL but CPython does.

"PEP 703 – Making the Global Interpreter Lock Optional in CPython" (2023) https://peps.python.org/pep-0703/

CPython built with --disable-gil does not have a GIL (as long as PYTHONGIL=0 and all loaded C extensions are built for --disable-gil mode) https://peps.python.org/pep-0703/#py-mod-gil-slot

"Intent to approve PEP 703: making the GIL optional" (2023) https://news.ycombinator.com/item?id=36913328#36917709 https://news.ycombinator.com/item?id=36913328#36921625

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

#13

Post by waldrews »

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?

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.

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

#15

Post by tln »

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 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.

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

#16

Post by kaashif »

westurner wrote: post #12
lopuhin wrote: post #8

Earlier quoted context omitted.

I think GraalPython does have a GIL, see https://github.com/oracle/graalpython/blob/master/docs/contr... - and if by "there is no such thing on those platforms" you mean JVM/CLR not having a GIL, C also does not have a GIL but CPython does.

"PEP 703 – Making the Global Interpreter Lock Optional in CPython" (2023) https://peps.python.org/pep-0703/ CPython built with --disable-gil does not have a GIL (as long as PYTHONGIL=0 and all loaded C extensions are built for --disable-gil mode) https://peps.python.org/pep-0703/#py-mod-gil-slot "Intent to approve PEP 703: making the GIL optional" (2023) https://news.ycombinator.com/item?id=36913328#36917709 https://…

This is pretty beside the point. The point is that X not having a GIL doesn't inherently mean Python on X also doesn't have a GIL.
Post reply on HN