GraalPHP Is A PHP JIT Implementation Built On GraalVM

[phoronix]

Phoronix: GraalPHP Is A PHP JIT Implementation Built On GraalVM

Oracle's GraalVM has seen language support well outside of Java/OpenJDK from Ruby to WebAssembly to R and Python. The newest language seeing an experimental implementation built atop GraalVM is PHP...

http://www.phoronix.com/scan.php?page=news_item&px=GraalPHP-GraalVM-PHP

[cen1]

Sounds like a lot of work for a mere thesis, could easily be worthy of a PhD.

[onlyLinuxLuvUBack]

I look and laugh,
aint nothing because we got HolyC,
HolyC > all , y'all .

[vladpetric]

Unfortunately the benchmarks cited look like toys.

When it's production ready, and independent benchmarks show significant speedups (hopefully without the memory gobbling typically associated with JVMs), I will most certainly take a closer look.

[tildearrow]

....and here I thought Java was slow.

[caligula]

Well, PHP shouldn't be CPU bound. Aggressive caching and scaling via workers should fix all perf issues.

[vladpetric]

....and here I thought Java was slow.

Java is definitely slow. The JVM doesn't necessarily have to be. The problem is that the JVM is tuned for Java (and maybe Scala).

For instance, every object is a reference - that's a Java thing, which puts a heavy burden on the garbage collector (so many more references to walk). The JVM doesn't mandate that - the higher level language could inline structs (like Swift does).

Anyway, this is all speculation. I'll be convinced when I see good realistic, third party, benchmarks.

[andrei_me]

Java is definitely slow. The JVM doesn't necessarily have to be.

Exactly!

The best part of the Java ecosystem is the JVM, everyone can complain/hate Java verbosity and the VeryLongFactoryBuilderPatternClassNames, but the JVM allowed us to have Scala, Clojure, Kotlin, and several years of experience in developing VM, JIT, etc that other languages could learn from instead of reinventing the wheel

[mdedetrich]

Java is definitely slow. The JVM doesn't necessarily have to be. The problem is that the JVM is tuned for Java (and maybe Scala).

For instance, every object is a reference - that's a Java thing, which puts a heavy burden on the garbage collector (so many more references to walk). The JVM doesn't mandate that - the higher level language could inline structs (like Swift does).

Anyway, this is all speculation. I'll be convinced when I see good realistic, third party, benchmarks.

Disclaimer: Full Time Scala Programmer

This isn't entirely true, the JVM is actually very fast (it can get to 1-3x C++ speeds) when warmed up. The JVM has techniques to deal with this reference problem that you speak of (escape analysis/inlining, etc etc).

The problem is that these optimizations happen at runtime, i.e. in C++ speak everything in JVM is virtual and then it becomes static when the JVM has determined that the method is a hotspot. This is also the issue when it comes to benchmarking because its actually incredibly difficult to isolate the "warming up" phase from the "inlined phase" (even in internal Java benchmarks). Ideally when benchmarking JVM code you want to exclude the warming up phase but this in reality this is very difficult

In certain cases, JVM can beat "equivalent" C++ code (albeit rarely) due to the following reasons

• Garbage collecting a large chunk of memory is much faster than doing it whenever an object is deallocated in C++ (RISC)
• The JVM actually knows what the hotspots are at runtime rather than the programmer guessing (although this is somewhat mitigated with PGO)

In general, although JVM is generally slower than C/C++ its much faster than other higher level languages and this is one of the reasons why its used so often (fyi, Twitter uses Scala in their backend, even in hotspots). GraalVM also substantially improves classical JVM performance, particularly for Scala.

Practically speaking (from personal experience) the bigger issue with JVM is more the memory usage than actual performance. You typically have to throw a lot of memory for JVM languages however again this is actually to improve performance (i.e. its faster to malloc a big chunk of memory vs doing it incrementally and very often).

[cen1]

Throwing around general terms like "Java is slow" is just bad. Slow for what use case? You could probably write 90% of software in Java and nobody would notice anything has slowed down. Sure, there are use cases where you really want the fastest execution possible (games, multimedia encode/decode..) ..use the best tool for the job. Same goes to PHP, sure it might not be the fastes in benchmarks but it will happily serve your webpages in completely acceptable performance.