Hacker News Reader

magaudeton Ruby+OMR JIT Compiler: What’s Next?

Chris is definitely an inspiration to many, myself included.

magaudeton Ruby+OMR JIT Compiler: What’s Next?

For those curious about background: https://blog.cloudera.com/blog/2013/02/inside-cloudera-impal...

magaudeton Ruby+OMR JIT Compiler: What’s Next?

While the 'Pitfalls' paper was implemented on top of the Testarossa compiler technology (that underlies the OMR compiler technology), the OMR project has spent a lot of engineering effort to make the technology more modular and easier to interact with.

While it doesn't invalidate the reasoning behind the 'Pitfalls' paper, we think that we're addressing the problem in a fairly different manner: Instead of providing a fully featured JIT compiler that you need to wedge the language into, we've instead chosen to create a more modular system that lets the JIT compiler be more customized to the target language and VM.

magaudeton Ruby+OMR JIT Compiler: What’s Next?

Thanks so much for posting this! That was exactly what I was curious about!

magaudeton Ruby+OMR JIT Compiler: What’s Next?

Alas, our connection Eclipse is only a legal one. We are an Eclipse Foundation project, but not directly related to the IDE. So won't have any impact on eclim. Sorry!

magaudeton Ruby+OMR JIT Compiler: What’s Next?

When you say "native languages" you mean a statically compiled language?

It's been done before with the technology underlying the OMR compiler component, however there is some work that would need to be done to support this.

In principle though, there's no reason it couldn't be done.

magaudeton The Ruby+OMR JIT

I really enjoy meeting up with the JRuby+Truffle people whenever I can at conferences. Though our approaches are really different, there's definitely a cross-pollination of ideas: I've taken huge amounts of inspiration about what could be possible from Chris Seaton's PhD work which was on JRuby+Truffle.

magaudeton The Ruby+OMR JIT

Not as well as I should be able to, for sure.

In my mind, I look at Truffle and Graal as a potential way forward to build new high performance JVM languages.

OMR I see as a way to build language runtimes in C/C++, and have a production pedigree.

magaudeton Ask HN: How Is Developing on a Linux VM in Windows?

It's great. I do it every day: Headless ubuntu image that I then use Cygwin's X server to SSH into and run xfce4-terminal.

Only disappointment has been my laptop's decreasing stability at the windows level... but I can't blame that on linux or running a VM :D

magaudeton The Ruby+OMR JIT

Someone out of band poked me to give an eye as to what I see the roadmap is. I'm currently working on getting the JIT working with Ruby trunk (https://github.com/rubyomr-preview/ruby/tree/ruby_2_4_omr_pr...).

Once that's stable, then I'd like to focus on trying to some of this code integrated into MRI upstream, perhaps as an experimental branch for the 2.5 development cycle, or as something that can be compiled in optionally.

In parallel, I'd like to work on improving performance . We've not put a lot of effort into performance, and have instead focused on compatibility and currency, so that we have a good base from which to grow performance on top of.

magaudeton The Ruby+OMR JIT

Thanks! That's definitely the exact hope we have for OMR as well.

Similarly, improvements in OMR can be shared among all languages using it; ie, because we build both IBM's Java JDK and Ruby on top of OMR, Ruby can benefit from investment in Java, and Java can benefit from improvements in the Ruby community.

magaudeton The Ruby+OMR JIT

I have some performance numbers from my original talk at RubyKaigi [1] [2].

Still a ways to to go, but we've built out a reasonable foundation to start with.

[1]: http://www.slideshare.net/MatthewGaudet/experiments-in-shari...

[2]: http://rubykaigi.org/2015/presentations/MattStudies

magaudeton The Ruby+OMR JIT

Officially, OMR is a meaningless title, like LLVM. Similar to LLVM, it once stood for something, but then we realized that it didn't actually match the project's 'charter' quite as well as we had hoped... but had grown fond of the name (also... finding new names is super hard).

Original definition was 'Open Managed Runtimes', but we can do more than just managed runtimes with OMR technology, and so that seemed to sell it short.

magaudeton The Ruby+OMR JIT

Whoops! That's actually an editing mistake: The Ruby+OMR preview is actually for Ruby 2.2 right now.

You can follow the work in progress on trunk (what will become Ruby 2.4 in December) here: https://github.com/rubyomr-preview/ruby/tree/ruby_2_4_omr_pr...

magaudeton The Ruby+OMR JIT

Author here: Feel free to AMA!

magaudeton Ruby 3x3: Matz, Koichi, and Tenderlove on the Future of Ruby Performance

Hey! thanks for the shout out. I would totally love to see more feedback as well!

We haven't turned on the issue tracker on that repo, but the glue has it's issues turned on: https://github.com/rubyomr-preview/rbjitglue

Working on smoothing this out a bit, and also currently working on upgrading the JIT to target 2.4

magaudeton Ruby 3x3: Matz, Koichi, and Tenderlove on the Future of Ruby Performance

Hey, OMR developer here.

Ruby+OMR is developed in three pieces: 1) the language independent core, then 2) The language dependent portions (i.e., the VM, and what we call the 'glue')

The language independent core is here: https://github.com/eclipse/omr. It's under active development, :)

I'm actually working on Ruby 2.4 support right now (supremely not prime time, but if you're curious, the branch is here: https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminar...)

magaudeton Projects That Are Making Fast Ruby a Reality

OMR Team member here: Glad to hear you had a good experience with our tech preview! We really appreciated the feedback you provided, and would definitely be willing to take more.

magaudeton Ruby 2.3.0 Released

Unfortunately no dates. We're still working on this, but we really want to do it right, so we're taking the time we need. Sorry!

magaudeton Ruby 2.3.0 Released

(IBMer working on said JIT here)

As Chris Seaton points out as well, we're not really open source yet. Working on getting there, but it's going to take time. The important thing now is that we can start talking with the community and making it more likely that when we do get open source, it can happen in a way consumable by the Ruby community.

magaudeton JVMLS 2015 – Multi-Language Runtime [video]

One of the key parts of this project is that we are using the code in production. Each piece is being used in our shipping releases like Java.

Open sourcing will happen. Doing it right is very important to us however, so we don't know when.

magaudeton JVMLS 2015 – Multi-Language Runtime [video]

(BTW: Count me as a very happy user of Bench9k. It's been a very appreciated tool here. I'm hoping to contribute some of our harness customizations back when I have the time to clean up the commits a little).

magaudeton JVMLS 2015 – Multi-Language Runtime [video]

Our approach allows us to integrate with the existing runtimes, enhancing them, rather than having a new implementation. The PyPy approach is capable of much bigger gains, but we can integrate directly into the existing language community, along with all extensions.