GraalVM is fascinating. Honest question: what are Oracle's plan for it? How does it serve them?
There is already an EE for it, so I guess they provide basic functionalities for free, and if you need additional features you have to pay?
GraalPy – A high-performance embeddable Python 3 runtime for Java
131–140 of 151 posts
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#132OP here. More details about this particular release are in the blog post at https://medium.com/graalvm/whats-new-in-graal-languages-24-1... Happy to answer any additional questions!
Hi, what's the deployment process like? Is there a program similar to warbler (for jruby) that builds a jar for a python program?
EDIT: I tried the native binary command here on a simple hello world script.
It downloaded some stuff in the background, built the entire python and java and embedded it into a 350 MB ELF binary on linux after 15 minutes of using 24 GB RAM and 100% CPU.
But I'd much prefer a smaller jar file which I can distribute cross-platform.
https://www.graalvm.org/uploads/quick-references/GraalPy_v1/...
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#133Earlier quoted context omitted.
> You can use GraalPy with GraalVM JDK, Oracle JDK, or OpenJDK https://www.graalvm.org/latest/reference-manual/python/
Thanks. I actually managed to run the quick example with Temurin Java 22. Maybe that is what they mean by "OpenJDK": java.vm.name=OpenJDK 64-Bit Server VM, java.vendor.version=Temurin-22.0.2+9
Have you turned on `-XX:+EnableJVMCI`?
https://www.graalvm.org/latest/reference-manual/embed-langua...
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#134Earlier quoted context omitted.
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.
The documentation says "Optimized if enabled via experimental VM option". (I linked in another thread.)
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#135Took a little digging to find that it targets 3.11. Didn’t see anything about a GIL. If you’re a Python person, don’t click the quick start link unless you want to look at some xml.
Happily, you can ignore the Maven XML and use Gradle instead, it's the next codeblock on the page, after "or": implementation("org.graalvm.polyglot:polyglot:24.1.0") implementation("org.graalvm.polyglot:python:24.1.0")
Gradle files are less verbose than the equivalent Maven pom.xml but Gradle tends to have other issues like: complex builds that are hard to maintain, not running on the latest JVM version without some wait time, and constantly breaking because Gradle makes breaking changes every release. I'm hoping the declarative Gradle experiment [0] helps with this.
Additionally if XML isn't your thing Maven is making a push for other formats in Maven 4 like HOCON [1].
[0] https://blog.gradle.org/declarative-gradle-first-eap [1] https://github.com/apache/maven-hocon-extension
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#136Earlier quoted context omitted.
> an OO system that looks like it has been bolted in, compared to Ruby I think the two languages just have different design philosophies. In Python, functions are fundamental and classes are built on top of them. In Ruby, objects are fundamental and functions (i.e. Procs etc) are themselves objects. You could just as well claim that in Ruby, functions look like they have been bolted in. For example, you can’t call a…
I agree. Python was designed in 1989 and it looks like the OOP we were doing in C (without the ++) back at the time. Objects were a struct with data and function pointers and we were passing them around as pointers. Python has self, explicit in function definition and implicit in function calls, and that self is really like the pointer to the struct. By the way, OO languages from the 90s (e.g. Java and Ruby) were des…
I think Python's OO is a bit suboptimal even if the goal was to have method-centric OOP like in C with classes. For example, mechanisms to hide information, a fundamental part of the OO paradigm, are hacky. You need to use name mangling.
Same applies to FP, a few things are weird and crippled. IMHO, the net result is that Python code tends to look longer and much more algorithmic than in Ruby, Smalltalk or various Lisps, where the language favors lots of little functions that call each other.
Things are changing a bit, though. For example, pattern matching (PEP 622) brings some conciseness. Fixing those other issues would be great.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#137OP here. More details about this particular release are in the blog post at https://medium.com/graalvm/whats-new-in-graal-languages-24-1... Happy to answer any additional questions!
Hi, what's the deployment process like? Is there a program similar to warbler (for jruby) that builds a jar for a python program? EDIT: I tried the native binary command here on a simple hello world script. It downloaded some stuff in the background, built the entire python and java and embedded it into a 350 MB ELF binary on linux after 15 minutes of using 24 GB RAM and 100% CPU. But I'd much prefer a smaller jar fi…
Thanks for the question, nurettin.
Although GraalPy can create standalone applications [1], you don't have to turn your hello world script into a self-contained binary. You can, of course, create a JAR that depends on GraalPy, or a fat JAR that contains it, and deploy it just like any other Java application.
We are still updating our docs to mention more details on this and publish some guides, apologies for the delay.
[1] https://www.graalvm.org/latest/reference-manual/python/stand...
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#138Tried 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…
Appreciate the further details, thanks! This is a huge undertaking, good luck, and I'll be checking back in here and there.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#139Tried 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 someth…
What I was hoping to be able to do was run our existing cpython project on graal to try and benefit from whatever speedups the jvm (or, if possible, compiling to a native module) would provide, rather than build with the jvm specifically in mind from the get go.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#140Earlier quoted context omitted.
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 someth…
What I was hoping to be able to do was run our existing cpython project on graal to try and benefit from whatever speedups the jvm (or, if possible, compiling to a native module) would provide, rather than build with the jvm specifically in mind from the get go.
That is a problem with Python as a language and a platform and has nothing to do with Graal. PyPy is in the same boat. If the alternative Python's banded together there would be 10.