comparison to graal / truffle

[dotnwat]

I'm just starting to learn about OMR, and have been investigating Graal and Truffle. If anyone has knowledge of both, I'd really appreciate the tl;dr about the differences between the projects, goals, and when one might be more appropriate than the other. Thanks!

[jduimovich]

Not sure there is tl;dr answer, since this one is already too long. Caveat, you on the OMR lists so any bias should be implied.

So, the short answer is that Truffle/Graal is research effort that is looking at using the JVM for implementing programming languages. Truffle is used to implement languages via implementing an AST parser and optimizing it via Graal (lots of details skipped). Graal focuses on code generation and relies on Java for garbage collection. You implement your language in Java. As many of the target languages use C/C++ as their implementation language, this could be a non-starter, but perhaps with TruffleC it could be used to re-compile directly but I don't think that is open source. They have some impressive benchmarks so there is cool stuff there.

OMR is a project whose goal is to create components for building reliable, high performance language runtimes. The core technology is from the IBM Java VM, which is a high performance production ready JVM used in many IBM products. It includes Garbage Collection, a JIT Compiler and lots of other stuff that is useful in building managed runtimes in C/C++.

The goal for OMR was to enable use of the same production code use by Java, but for new use cases we're seeing in the Cloud, essentially polyglot, use of ruby, python, node and others require high performance implementations of these languages. We found that we were being asked to optimize or look at these runtimes, and we want to be able to reuse our code- hence modularized functionality and open source. The other goal was to provide some consistency across languages, including tools, and tuning. OMR is written in C/C++ with the intent that consumer languages can integrate incrementally. You can add a JIT or a GC to your existing C/C++ code so it may be more approachable for some projects because they can continue what they were doing, and decide where Eclipse OMR pieces could help. Many systems need a optimizing JIT, others need better GC (which you probably don't want to write yourself ) and you don't want (typically) to rehost from scratch on a new platform. The intent for OMR is to not require consuming projects to fork, and change implementation platforms to benefit, which hopefully offers an incremental path .

So, if I was to make it short. Truffle/Graal - a cool research project with impressive numbers, Java based which is good for interop (if you want it) and for new language implementors Java could be more approachable. You do need to re-host on it as your platform and some of it is not open source (yet). If I was a student, wanted to try a new language implementations, I would probably start with this.

Eclipse OMR, is production ready code, used by IBM Java, and trying to bootstrap into other languages, has good benchmarks in Java, but for other languages proof points are still in progress as OMR is about 1 year old as an open source project. An existing language implementer, would not need to re-write their C/C++ implementation so they could incrementally adopt components. If you want a code gen library to integrate, or a separate GC implementation to integrate, you would pick OMR as they are provided as modular components. In terms of learning how to build typical bytecode based runtimes, even for students, OMR is fairly approachable. We'd done workshops using the technology using a simple bytecode engine and it's worked out well. See https://github.com/youngar/Base9

Hope this helps, thanks for your interest.

[dotnwat]

At a high-level that really covers 100% of what I was interested in. Thanks a lot for taking the time to write this.

[mstoodle]

Same preface comment about obvious implied bias :) .

I suppose one further comment I will add to John's excellent summary would be that Eclipse OMR is implemented (mostly) in C/C++ but that does not mean it can only be used from C/C++ since most languages already have a good interop story with C/C++.

For example, I demonstrated at JVMLS last year how Java bindings can be written for the OMR JitBuilder library so it can be used to generate native code dynamically with Java code, providing direct access to features like SIMD instructions (I showed how to vectorize a matrix multiply operation). If you're interested and haven't seen it, that presentation is here: https://www.youtube.com/watch?v=w5rcBiOHrB0

Bindings for other languages are also possible, of course. It is also possible to create a textual/binary JitBuilder IR description (language?) that could be easily produced from any language.

Graal/Truffle, on the other hand, are implemented within the Java ecosystem, which has an interop story that mostly involves re-implementing other languages on top of the JVM (using Graal/Truffle in many cases). Java is amazing, but not everyone seems to want a JVM in their runtime.

We obviously prefer our approach and are going to continue to improve the OMR technology :) .

Thanks for your interest!

[mgaudet]

We should really link to this from the README

[thomaswue]

Graal runs core Twitter services in production by now (https://twitter.com/thomaswue/status/914916691884302336). So the "cool research project" is getting mature. The biggest innovation in Truffle is btw the use of partial evaluation to automatically derive a compiler from a self-specializing interpreter. It is described in this research paper: http://chrisseaton.com/rubytruffle/pldi17-truffle/pldi17-truffle.pdf

[ashu-mehra]

This talk by Christian Thalinger provides more details on Twitter services running on Graal.

[dotnwat]

I love that this thread keeps getting attention even after almost a year :)