GraalPHP Is A PHP JIT Implementation Built On GraalVM

[mdedetrich]

Have you ever worked on a compiler pass?

Yes at uni

Anyway, the problem with a JIT - when compilation time becomes running time - does not stem from assembly generation. That is primarily one (or a maybe couple) of passes. But you do a couple dozen other passes before that for optimization (in gcc the total number of passes is above 100, though in llvm it's lower than that).

Right, but you do realize that this is done by design and not necessarily a part of optimization? For example, C++ has its own templating system which requires a very expensive pass for the compiler because it is its own turing complete language and a lot of C++ projects make heavy use of templates.

Java doesn't have this which of course, it doesn't meant the JVM is "worse" because its not doing a pass that is not required by design

With respect to unoptimizing/deoptimizing - it's absolutely a real thing. You should have read the classic Jalapeno paper https://ieeexplore.ieee.org/document/5387060 . In C++ you don't need to worry about that, but in Java you do.

You do realize that de-optimization is done due to performance/memory right? This happens when a "hot" method is no longer hot and has no actual real performance benefitrs in being optimized. Not sure you realize, some quick googling will show you this i.e. https://stackoverflow.com/q/20522870

i.e. you are saying that this is a bad thing when in reality its not, otherwise the JVM wouldn't do it.

With respect to the language being too dynamic - let me give you another example: having all methods virtual by default is a bad idea for correctness as well (I'd much rather have virtual methods explicit, and the compiler warn on non-explicit override).

Correctness with respect to what? There is nothing incorrect about virtual (or non virtual methods) for that matter. Maybe you meant to say explicit vs non-explicit but then this is about tradeoffs.

Hint, apart from some very basic rule of thumb optimizations, when doing micro-optimizations for C/C++ code a lot of the time programmers get it wrong, i.e. the optimizations they have generally are not useful for real world running of the program because their assumptions were incorrect.

Why do you think PGO (profile guided optimization) exists? Its basically doing the same thing as JVM but in reverse, i.e. JVM assumes everything is virtual and then optimizes when a method is actually a hotspot where as PGO takes runtime executions to profile a compiled program.

With respect to profiling - the Hotspot-derived JVMs don't do profiling of active, optimized code (or continuous profiling). What they do is lazy compilation - they start by interpreting code, while keeping counters for the basic blocks encountered. Once a basic block reaches a certain threshold, the whole method is compiled. The problem is - that's it, there's no continuous profiling in Hotspot-derived JVMs of the optimized code (it's really easy to prove me wrong here though - pointer to code that does it).

You are right but for a really old version of Java (i.e. <=1.4 iirc) which is about 20 years ago. Current Java does continuous profiling, its called tiered compilation and you can read about it here https://advancedweb.hu/jvm-jit-optimization-techniques/ .

Also have a look at GraalVM, it does AOT compilation as much as possible and creates actual native image binaries, basically removing the startup issues of the traditional JVM as well as adding a lot more compilation phases (I mean compile time compilation, not runtime compilation), i.e. https://www.slideshare.net/scalaconf...-flavio-brasil

The point about Swift and Golang, both languages that are much much younger than Java, and not nearly as performance tuned, is that they allow for more flexible memory management -

Golang is always going to be slower by design because of the author of the language has certain design goals. Robert Pike prioritizes faster compile times over faster binaries, he has stated this many times. One of the whole points of Go is that it fixes a quality of life issue when it comes to compilation statically compiled languages that it was competing with in Google (primarily C++/Java).

So yes Java has a head start, but Go is never going to be as fast as Java even if you account for this. There are also a lot of design reasons why Go is slow, i.e. it doesn't have generics/polymorphic parametirzation which means that runtime checks need to be carried out on generic algorithms (something that Java/C++ doesn't need to do).

for instance, you can both use links (references) and inline the data. As a developer it's really useful to have that choice, and it's a bad idea to leave that task to the compiler. (Again, it would be good if language designers stopped treating the compiler like a sewer system).

Sure this is a tradeoff, Java was literally designed to take away control over the optimizations because the assumption is that a compiler happening at runtime with runtime information is going to be generally better at optimization compared to a human when taking into account the human cost of manual memory management and this is generally true otherwise Java would not be where it is now.

This I agree with, but that is very different to saying that Java is generally slow which is what you are implying, its not. Python and Ruby are generally slow (at least when they are not using libraries that are just FFI to C libraries e.g. numpy)

As far as speed is concern, right now Swift is actually reasonably fast except for three benchmarks here (and for two of them, I'd suspect that the swift standard library is slow):

https://benchmarksgame-team.pages.de...est/swift.html

Those benchmarks seem invalid because they are taking into account the warming up phase of the JVM which as stated before is an apples vs oranges comparison.

Please don't post invalid benchmarks, its not doing you any favours.

Given your tone you seem to be part of the Make Java Great Again! party.

Java (or more accurately the JVM since the language is starting to show its age) is already great otherwise people wouldn't be using it.

Judging from your tone, you seem to have a personal problem with a language being successful, did Java kill your cat or something?

Also your understanding of the JVM is really outdated, like I am talking 15-20 years.

[igouy]

Those benchmarks seem invalid because they are taking into account the warming up phase of the JVM which as stated before is an apples vs oranges comparison.

My guess is that you mean those measurements include the warming up phase.

As you say —

Ideally when benchmarking JVM code you want to exclude the warming up phase but this in reality this is very difficult

Those measurements may be less than ideal, but you are too quick to dismiss them.

Ask How much difference does it make for these tiny programs?

[mdedetrich]

My guess is that you mean those measurements include the warming up phase.

As you say —

Those measurements may be less than ideal, but you are too quick to dismiss them.

Ask How much difference does it make for these tiny programs?

Right, they are using conclusions from one sample and then extrapolating it to every other case (just because warmup phase is negligible in one benchmark doesn't mean its generally negligible). Also I have no idea what the JVM parameters are (you can configure the JVM to be faster in shorter run "scripts").

Sorry, I would prefer something more scientific. Actually for such benchmarks they really should be using GraalVM with an AOT compiled native image (since this also better targets the usecase, i.e. short run programs vs long running server programs).

[igouy]

extrapolating it to every other case

That is a misrepresentation, the statement is clear — "How much difference does it make for these tiny programs?"