3 ms·

Graal is pretty brand new in the relative scheme of things, it's not going to be amazing out of the box. (I'll ignore the "LLVM has a JIT" part) Really. There

Graal is pretty brand new in the relative scheme of things, it's not going to be amazing out of the box. (I'll ignore the "LLVM has a JIT" part) Really. There is no magic here. The way you get compilers with 100% or greater perf of gcc/llvm is not through silver bullets. It's through a large amount of hard work and tuning. IE hundreds of person years. It's usually easy to get the first 60-70%, and then people say "see, we didn't need <heavyweight thing>, we'll beat them with <lightweight thing>". But if you have customers where no performance is ever "good enough", getting that 30%, and eventually beating other compilers, is the thing that takes 10+ years. You'll never do it with <lightweight thing>. That's why all these folks who try eventually end up with 3 layers of compilers, etc. If it could have been done with <lightweight thing>, it would have been done that way. Also, you can just about always transfer the metadata necessary to do high level optimization x at a lower level. it just may not be efficient to do so. Conversely, compilers that focus on fairly high level optimizations often do a bad job at lower level ones :) Again, tradeoffs, tradeoffs. (This is why, for example, swift/rust/etc have some higher level IR, do what they can, and hand the rest off to llvm).

mike_hearn 10y ago
Fully agree that it's a ton of work to build a production quality compiler. Graal is "new" only in the sense that it only recently got good enough for people to care about it. It's actually been in development for years ... arguably close to a decade now given that it traces its heritage back to the Maxine VM. Graal's generated code quality is similar to HotSpot C2 i.e. the fastest available Java JITC, at least for most ordinary benchmarks (I have a feeling it may be weaker at auto-vectorisation than C2 but I'm not sure). Where Graal really spanks the competition is with more dynamic languages like Scala or Ruby though. There it sees huge speedups compared to other state of the art compilers. Graal can also JIT/AOT compile LLVM bitcode. I don't know what performance is like for that, but earlier prototypes that JITd C ASTs directly could compile C with performance about 7% worse than GCC/clang (best of for each benchmark). The last 7% will take some work I guess but it's not infeasible. There's a long term plan to make Graal the default JIT compiler in HotSpot. The problem at the moment is it - no surprise - it uses more memory than C2, and shares the same Java heap as the application.

mike_hearn 10y ago

Fully agree that it's a ton of work to build a production quality compiler. Graal is "new" only in the sense that it only recently got good enough for people to care about it. It's actually been in development for years ... arguably close to a decade now given that it traces its heritage back to the Maxine VM. Graal's generated code quality is similar to HotSpot C2 i.e. the fastest available Java JITC, at least for most ordinary benchmarks (I have a feeling it may be weaker at auto-vectorisation than C2 but I'm not sure). Where Graal really spanks the competition is with more dynamic languages like Scala or Ruby though. There it sees huge speedups compared to other state of the art compilers. Graal can also JIT/AOT compile LLVM bitcode. I don't know what performance is like for that, but earlier prototypes that JITd C ASTs directly could compile C with performance about 7% worse than GCC/clang (best of for each benchmark). The last 7% will take some work I guess but it's not infeasible. There's a long term plan to make Graal the default JIT compiler in HotSpot. The problem at the moment is it - no surprise - it uses more memory than C2, and shares the same Java heap as the application.