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

121–130 of 151 posts

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

#121

Post by mike_hearn »

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…

The number of patches is going down with time and many are trivial one liners, e.g. uvloop

https://github.com/oracle/graalpython/blob/b907353de1b72a14e...

    -        self.cython_always = False
    +        self.cython_always = True
That's the entire patch. Others are working around bugs in the C extensions themselves that a different implementation happens to expose, and can be upstreamed:

https://github.com/oracle/graalpython/blob/b907353de1b72a14e...

Still others exist for old module versions, but are now obsolete:

https://github.com/oracle/graalpython/blob/b907353de1b72a14e...

    # None of the patches are needed since 43.0, the pyo3 patches have been upstreamed
And finally, some are just general portability improvements. Fork doesn't exist on Windows. Often it can be replaced with just starting a sub-process.

So the patching situation has been getting much better over time, partly due to the GraalPy team actively getting involved with and improving the Python ecosystem as a whole.

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

#122

Post by steve_s »

RMPR wrote: post #85
theLiminator wrote: post #51

Earlier quoted context omitted.

I wonder if hpy will solve the extension problem.

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/#limite...

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.

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

#123

Post by masklinn »

mike_hearn wrote: post #119
masklinn wrote: post #110

Earlier quoted context omitted.

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/lat…

> Which version was that with?

24.1. 23 may or may not have been worse, I didn’t take specific notes aside from “too slow to be acceptable”

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

#124

Post by Rochus »

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

That is why we should always use a standardized, controlled benchmark suite, which has well-defined rules to assure fair cross-language comparisons with a representative, well-balanced workload. By focusing on a core set of language features and abstractions, Are-we-fast-yet allows for a more controlled comparison of language implementation performance, isolating the effects of compiler and runtime optimizations.

This is especially important for scripting languages like Python, where a large part of the features are implemented in C or other native languages and called via FFI. That's why, for example, the benchmark implements its own collections, because we want to know how fast the interpreter is. Otherwise, as you have noticed, the result is randomly influenced by how much compute a particular application can delegate to the FFI.

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

#125

Post by pmontra »

pansa2 wrote: post #93
nextos wrote: post #92

Earlier quoted context omitted.

It's a shame Python has a strong anti-FP stance with crippled lambdas. And an OO system that looks like it has been bolted in, compared to Ruby which is essentially a Smalltalk with Perl-like syntax and some Lisp influence. These two issues would have been quite easy to fix and would have led to a completely different development experience. Python had a good implementation with a nice C FFI (CPython) right from the…

> 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 designed to always hide that self, both in method definition and method call. They use it when there is a need to tell the difference between instance attributes and local variables with the same name.

Maybe the explicit self was there to make C programmers feel at home. Functions as fundamental building blocks of the language also make C programmers feel at home. Developers got more familiar with OOP by mid 90s so the new languages could jump from functions-first to objects-first.

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

#126

Post by t43562 »

pansa2 wrote: post #94
Myrmornis wrote: post #84

Earlier quoted context omitted.

I think your comment needs to mention that Python has syntax for type annotations and two mature type checkers (mypy and pyright) with more under development. Python is thus very much part of the modern statically typed languages scene (moreso than Go) whereas Ruby isn't at all. Many people wouldn't touch Python today if it weren't for this.

> two mature type checkers I’ve never quite understood how this works. Surely a type system is absolutely fundamental to a language - how can you have multiple incompatible ones? Do you need to choose a particular type checker for each project? Are you limited to only using third-party libraries that use the same type checker?

I think Python was successful because it started off without a type system and you can still choose not to use it. Duck typing is the big feature really.

It might float your boat to think about types but why would everyone have to want the same thing?

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

#127

Post by masklinn »

Rochus wrote: post #124
masklinn wrote: post #110

Earlier quoted context omitted.

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

That is why we should always use a standardized, controlled benchmark suite, which has well-defined rules to assure fair cross-language comparisons with a representative, well-balanced workload. By focusing on a core set of language features and abstractions, Are-we-fast-yet allows for a more controlled comparison of language implementation performance, isolating the effects of compiler and runtime optimizations. Thi…

> That's why, for example, the benchmark implements its own collections, because we want to know how fast the interpreter is. Otherwise, as you have noticed, the result is randomly influenced by how much compute a particular application can delegate to the FFI.

That sounds like the exact opposite of what I would want as a user of the language: the benchmark completely abstracts the actual behaviour of the runtime, claiming purported gains which don’t come anywhere near manifesting when trying to run actual software.

I’m not implementing my own collections when `dict` suffices, and I don’t really care that a pure python version of `re` runs faster in graal than in cpython, because I’m not using that.

So what happens is I see claims that graalpython runs 17 times faster than cpython, I try it out, it runs 6 times slower instead, and I can only conclude that graal is a worthless pile of lies and I should stop caring.

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

#128

Post by Rochus »

masklinn wrote: post #127
Rochus wrote: post #124

Earlier quoted context omitted.

That is why we should always use a standardized, controlled benchmark suite, which has well-defined rules to assure fair cross-language comparisons with a representative, well-balanced workload. By focusing on a core set of language features and abstractions, Are-we-fast-yet allows for a more controlled comparison of language implementation performance, isolating the effects of compiler and runtime optimizations. Thi…

> That's why, for example, the benchmark implements its own collections, because we want to know how fast the interpreter is. Otherwise, as you have noticed, the result is randomly influenced by how much compute a particular application can delegate to the FFI. That sounds like the exact opposite of what I would want as a user of the language: the benchmark completely abstracts the actual behaviour of the runtime, cl…

If you don't know exactly what you are measuring, the measurement is worthless. We must therefore isolate the measurement subject for the measurement, and avoid uncontrollable influences as far as possible. This is how engineering works, and every engineer should also be aware of measurement errors. In addition, repeatability and falsifiability of the experiment and conclusions are required for scientific claims. The mere statement "too slow to be acceptable" or "worthless pile of lies" is not enough for this.

A measurement method does not have to represent every practical application of the measured subject. In the present case, the measurement allows a statement to be made about the performance of the interpreter (CPython) in relateion to the JIT compiler (GraalPy). Whether the technology is right for your specific application or not is another question.

Post reply on HN