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

51–60 of 151 posts

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

#51

Post by theLiminator »

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…

I wonder if hpy will solve the extension problem.

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

#52

Post by _ea1k »

pvorb wrote: post #35
andreldm wrote: post #29

Earlier quoted context omitted.

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.

Did you look into Jython back then?

Jython was dead for a long time. It might be back a little now, but there is still no Python 3 support.

GraalPy is much more active and more compatible.

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

#53

Post by Eridrus »

yosefk wrote: post #34
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?

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.

It didn't happen by total accident, but it didn't happen by design for where we are today either. The original choice to start building data science tooling in Python happened intentionally, but since then path dependence has been a huge thing.

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

#54

Post by wenc »

yosefk wrote: post #34
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?

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.

As a former Perl hacker who started using Python in 2005, I saw Python ride several waves. (Numerical computation, data science, deep learning)

Perl was the leading tool for scripting and text parsing. Python didn’t really supplant it for a long time — until people started writing more complicated scripts that had to be maintained. Perl reads like line noise after 6 months whereas I can look at Python code from 20 years ago, prettify it with black, and understand it.

Python got picked up by the scientific computing community, which gave it some its earliest libraries like numpy, f2py, scipy. Some of us who were on MATLAB moved over.

Then data science happened. Pandas built off the scientific computation foundations and eventually libraries like scikit and matplotlib (mimicking matlab’s plotting) came along.

Then tensorflow came along and built on the foundation of numerical libraries. PyTorch followed.

Other systems like Django came and made python popular for building database backed websites.

Suddenly there was momentum and today almost all numerical software have a python API — this includes proprietary stuff like CPLEX and what have you.

Python was the glue language that had the lowest barrier of entry. For instance, Spark was written in Scala and has a performant Scala API but everyone uses PySpark because it’s much more accessible, despite the interop cost.

The counterfactual to all this was Ruby. It had much nicer syntax than Python but when I tried to use it in grad school I was quickly stymied by the lack of numerical libraries. Ruby never found a niche outside of Rails and config management.

Essentially Python — like Nvidia today — bet on linear algebra (and more broadly on data processing) and won.

I get why there’s hate for Python — it’s not a perfect language. Yet those of us pragmatists who use it understand the trade offs. You trade off on the metal performance for programmer performance. You trade off packaging difficulties for something that works. You trade off an imperfect syntax for getting things done.

I could have used Ruby — a much more beautiful lanaguage — in grad school and worked around its lacks, but I would have not graduated on time. Python was pragmatic choice for me and continues to be one for me today (outside of situations requiring raw performance)

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

#57

Post by actionfromafar »

theflyinghorse wrote: post #45
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.

Picture working for a big, non-tech corporation. Your BU only does Java because it has always been thus and Jeff the SVP is a law grad and doesn't want anything to change because of perceived risk. GraalVM allows smart people who have to work within such limitations to still write (mostly) the software they want while still vaguely relating it to Java for decision makers.

Not so vaguely, either. The dev story is not Java but the deploy story is.

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

#58

Post by kaba0 »

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.

Besides all the nice answers given by others, a big one was not mentioned: performance!

Graal can do pretty advanced JIT-compilation for any Graal language, plus you can mix-and-match languages (with a big chunk of their ecosystems) and it will actually compile across language boundaries. And we haven’t even mentioned Java’s state of the art GCs that can run circles around any tracing GC, let alone the very low throughput reference counting.

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

#59

Post by kaba0 »

w10-1 wrote: post #46
ackfoobar wrote: post #32

Earlier quoted context omitted.

Graal is many things (a marketing nightmare). The guest language part is orthogonal to the native packager AFAIK.

Yes, but I was under the impression that graal-level inter-op was limited to packages the graal toolchain could compile. Thus, while swift and graal both depend on llvm, they use different variants and there's no real way to make inter-op between swift and graal (even using the llvm it which graal is said to be able to consume). e.g., I believe this announcement represents the work to compile a python (3.11) and some…

I don’t really see how swift comes into the picture, besides SuLong being a thing (running LLVM bitcode). Native binary was meant as a compile target in the previous comment, I believe, not as an input. Graal can do both, but as a target it has no dependency on LLVM.

So yeah, graalvm should be able to produce a native binary for python code (though depending on the specifics it might actually be more like a native binary interpreter running python scripts, it can’t optimize in every circumstance but I’m hazy on the details).

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

#60

Post by Rochus »

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 (geomean) faster on JDK8 than on GraalPython EE 22.3 Hotspot, or 41 times faster than CPython 3.11. GraalPython is thus about 17 times faster than CPython, and about two times faster than PyPy. The Graal Enterprise Edition (EE) seem to be factor 1.31 faster than the Community Edition (CE).

Post reply on HN