15 ms·

The Ruby+OMR JIT

109 points by x3qt 10y ago

rubyfan 10y ago
Anyone have any performance comparisons against other Ruby implementations? I assume performance is the main reason someone would adopt this right?
- vinceguidry 10y ago
  This is an improvement to standard MRI Ruby, also called CRuby. This is an experimental JIT compiler which probably won't get adopted into mainline Ruby, but will definitely cross-pollinate with it. A JIT compiler has been a goal in MRI development for a long time. Nobody is likely to adopt this for anything, it would take more work to get this working with the current installed base of Ruby code than it would be to just rip ideas from it and put them into Ruby 3. It's just cool as a proof of concept. Other Ruby implementations suffer from not being compatible with the MRI ecosystem, you have to port them over. In theory because they're the same language, gems would be easily portable, but the sheer amount of combinatorial work involved means they slowly accrete into separate ecosystems. It's relatively easy to port a gem over and maintain it, but if you don't keep doing it, they'll become incompatible. MRI has the largest install base, and the biggest gem library, and the largest number of eyes on it. Sure, JRuby and Rubinius are faster, but Ruby was never a language chosen for speed, so most devs reach for MRI first and then only branch out when requirements force them out. For me, the differences between MRI and other implementations effectively make them different languages, I'd jump to Elixir before giving JRuby a shot. I have a sense that other Rubies, except maybe Opal, will always be niche.
  - rurounijones 10y ago
    > or me, the differences between MRI and other implementations effectively make them different languages, I'd jump to Elixir before giving JRuby a shot Wha? Sorry but this sounds pretty FUDdish. I have never had an issue with JRuby to the extent that you are describing. Do you have some examples? I know of many large app deployments in JRuby at large household name companies. The only thing JRuby doesnt have is the relatively niche CExt functions.
    - rogerdpack 10y ago
      I use jruby on my hobby projects at time (GUI support is great!) however...the startup time is...always...so...awful...it is truly painful. I'm basically moving on to either crystal or go now, it just wasn't worth it anymore.
  - coldnebo 10y ago
    The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support. So, yes, on the surface of it, this particular Ruby build might appeal to people looking for performance. But from a language research position it is interesting to decouple concepts like GC from the language so that they can be studied and optimized as a pattern and then be potentially reapplied to any language runtime. I agree that some concepts might be pulled into MRI Ruby 3, but OMR may be a powerful testbed for language researchers to debate GC strategies and measure effects in various languages before committing to a single language integration.
    - magaudet 10y ago
      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.
    - dragonwriter 10y ago
      > The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support. It may be worth rembering that today's (1.9 and later) "MRI" started life as an alternative to MRI called "YARV". For a while there was a lot of talk about Rubinius as potentially being the basis of a similar replacement and becoming the "MRI" of the future. While there is less talk recently about Rubinius in that role, its absolutely not impossible that a competing core engine could be adopted as the mainline implementation of Ruby again.
      - ksec 10y ago
        That is assuming, 1. It is mostly compatible with Gems. 2. It is faster and accepted by the Core Team. 3. Most importantly, license. Both MRI and YARV, the two CRuby implmentation are all MIT. It is highly unlikely JRuby or OMR could be used as mainline.
  - LeanderK 10y ago
    As somebody not into the whole ruby-ecosystems: What's an example that breaks compatibility between ruby and other implementations? And what's so wrong with JRuby that you won't even consider it?
    - coldnebo 10y ago
      Rubygems forms an ecosystem of libraries on top of Ruby. Most gems are dev/tested within MRI, some work across other Rubies, some do not. It's difficult to tell which is which. This means most teams choose MRI in much the same way that most Ruby teams choose some form of unix -- compatibility. Ruby also suffers from the lack of a formal VM, so other implementations are merely similar rather than being guaranteed to run all programs. This is not the same with JVM vendors, where choice of IBM vs Oracle is largely based on extrinsic features rather than intrinsic compatibility. (Or at least you have to get in really deep to find differences-- in Rails you usually find incompatibilities that stop you from even starting the app).
    - coldnebo 10y ago
      Re: jruby I have considered it deeply. Many of our enterprise systems are Java-based, so JRuby's ability to call Java methods directly without implanting services would be a huge pragmatic boon. But every time I consider that I have to balance it against being able to use a constellation of gems in Rails. For example, nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, but that isn't the issue. Rather I would have to reimplement or find replacements for everything we use that depends on that without introducing side-effects. In my experience that's really hard unless it's a toy application without many dependencies. (Read: opposite of most enterprise Ruby apps) Also, as a gem author I've tried to support jruby along with MRI, but it requires jumping through a lot more hoops. Of course any cross-platform code requires more work to support, but it's a pressure on small devs. If no one needs it, no one helps support it, so then it becomes another gem that is effectively MRI-only. Kind of a viscous cycle.
      - rurounijones 10y ago
        > nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, Nokogiri natively supports JRuby, no equivalent searching required. CExts are basically the only place where this issue really pops up and all the major CExt gems (Like nokogiri) support JRuby.
  - rubyfan 10y ago
    Interesting, For many years I was all in on MRI and down on JRuby but over recent years I've been quite happy with JRuby for certain things. The reality of JRuby startup times make it not a good fit for scripting tasks but otherwise server and threaded tasks are a great fit. Since using JRuby more recently I feel the ecosystem support is probably the best of the non-MRIs. I rarely run into compatibility issues. Conversely JRuby's Java integration has been a very useful feature that no other Ruby implementation offers.
- magaudet 10y ago
  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-sharing-java-vm-technology-with-cruby http://www.slideshare.net/MatthewGaudet/experiments-in-shari... [2]: http://rubykaigi.org/2015/presentations/MattStudies http://rubykaigi.org/2015/presentations/MattStudies
appleflaxen 10y ago
Tried looking in github, project-specific pages, wikipedia and still have no clue: What does OMR stand for? <something><something>runtime?
- coldnebo 10y ago
  Doesn't seem to stand for anything (at least it's not defined in the project charter). If I had to guess at it: Open Meta-Runtime But I could see how that might be misinterpreted compared to their goals. Not all cap names are acronyms? https://projects.eclipse.org/proposals/omr https://projects.eclipse.org/proposals/omr
  - forkandgrok 10y ago
    It stands for Open Managed Runtime.
    - rubyfan 10y ago
      Is the Open really open, as in acceptable license that won't hold it back from gaining adoption in OSS and Enterprise community - or - are there licensing, patents or other proprietary strings attached?
      - sanxiyn 10y ago
        OMR is under Apache License. https://github.com/eclipse/omr https://github.com/eclipse/omr
- magaudet 10y ago
  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.
deleted 10y ago
[deleted]
skeptic2718 10y ago
I expected CPython to have something like this, especially in 3.x but nothing. If Ruby can get faster than Python sooner, I'd switch focus to Ruby (and somewhat make Go less of a priority for us).
- orf 10y ago
  What's wrong with PyPy?
  - my123 10y ago
    Good Python 3.x support...
  - progman 10y ago
    Developers who like Python syntax and want C performance should seriously consider Nim. http://nim-lang.org http://nim-lang.org
    - weberc2 10y ago
      What's the library story for Nim? Sincere question; not trying to start a flame war.
      - dagw 10y ago
        http://nim-lang.org/docs/lib.html http://nim-lang.org/docs/lib.html However many of the libraries list under "third party" are either unmaintained or not really ready for production. The stuff in the standard library seems pretty good though (although I've not used Nim for serious production work)
  - brianwawok 10y ago
    It's like the bad parts of Java mixed with Python to get a little more perf
    - orf 10y ago
poorman 10y ago
"Right now, it only works for Ruby 2.1.5; however, I'm slowly plugging away at moving forward towards Ruby 2.4." The irony. But in all seriousness, this is awesome.
- magaudet 10y ago
  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_preliminary https://github.com/rubyomr-preview/ruby/tree/ruby_2_4_omr_pr...
deleted 10y ago
[deleted]
magaudet 10y ago
Author here: Feel free to AMA!
- magaudet 10y ago
  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_preliminary 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.
- noahdesu 10y ago
  Slightly off topic since the post is specific to Ruby, but are you able to compare OMR to Truffle and Graal?
  - magaudet 10y ago
    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.
    - wgjordan 10y ago
      Related, are you aware of the JRuby+Truffle project [1]? Not a new high performance JVM language, but a high-performance implementation of Ruby using Truffle and Graal. On the surface it sounds extremely similar to Ruby+OMR (applying a high-performance, production-pedigree compiler/interpreter to an experimental Ruby implementation), so I'd be interested in hearing about any direct comparisons or knowledge-sharing between the two projects that might be possible. [1] https://github.com/jruby/jruby/wiki/Truffle https://github.com/jruby/jruby/wiki/Truffle
deleted 10y ago
[deleted]

109 points by x3qt 10y ago

Anyone have any performance comparisons against other Ruby implementations? I assume performance is the main reason someone would adopt this right?

vinceguidry 10y ago
This is an improvement to standard MRI Ruby, also called CRuby. This is an experimental JIT compiler which probably won't get adopted into mainline Ruby, but will definitely cross-pollinate with it. A JIT compiler has been a goal in MRI development for a long time. Nobody is likely to adopt this for anything, it would take more work to get this working with the current installed base of Ruby code than it would be to just rip ideas from it and put them into Ruby 3. It's just cool as a proof of concept. Other Ruby implementations suffer from not being compatible with the MRI ecosystem, you have to port them over. In theory because they're the same language, gems would be easily portable, but the sheer amount of combinatorial work involved means they slowly accrete into separate ecosystems. It's relatively easy to port a gem over and maintain it, but if you don't keep doing it, they'll become incompatible. MRI has the largest install base, and the biggest gem library, and the largest number of eyes on it. Sure, JRuby and Rubinius are faster, but Ruby was never a language chosen for speed, so most devs reach for MRI first and then only branch out when requirements force them out. For me, the differences between MRI and other implementations effectively make them different languages, I'd jump to Elixir before giving JRuby a shot. I have a sense that other Rubies, except maybe Opal, will always be niche.
- rurounijones 10y ago
  > or me, the differences between MRI and other implementations effectively make them different languages, I'd jump to Elixir before giving JRuby a shot Wha? Sorry but this sounds pretty FUDdish. I have never had an issue with JRuby to the extent that you are describing. Do you have some examples? I know of many large app deployments in JRuby at large household name companies. The only thing JRuby doesnt have is the relatively niche CExt functions.
  - rogerdpack 10y ago
    I use jruby on my hobby projects at time (GUI support is great!) however...the startup time is...always...so...awful...it is truly painful. I'm basically moving on to either crystal or go now, it just wasn't worth it anymore.
- coldnebo 10y ago
  The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support. So, yes, on the surface of it, this particular Ruby build might appeal to people looking for performance. But from a language research position it is interesting to decouple concepts like GC from the language so that they can be studied and optimized as a pattern and then be potentially reapplied to any language runtime. I agree that some concepts might be pulled into MRI Ruby 3, but OMR may be a powerful testbed for language researchers to debate GC strategies and measure effects in various languages before committing to a single language integration.
  - magaudet 10y ago
    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.
  - dragonwriter 10y ago
    > The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support. It may be worth rembering that today's (1.9 and later) "MRI" started life as an alternative to MRI called "YARV". For a while there was a lot of talk about Rubinius as potentially being the basis of a similar replacement and becoming the "MRI" of the future. While there is less talk recently about Rubinius in that role, its absolutely not impossible that a competing core engine could be adopted as the mainline implementation of Ruby again.
    - ksec 10y ago
      That is assuming, 1. It is mostly compatible with Gems. 2. It is faster and accepted by the Core Team. 3. Most importantly, license. Both MRI and YARV, the two CRuby implmentation are all MIT. It is highly unlikely JRuby or OMR could be used as mainline.
- LeanderK 10y ago
  As somebody not into the whole ruby-ecosystems: What's an example that breaks compatibility between ruby and other implementations? And what's so wrong with JRuby that you won't even consider it?
  - coldnebo 10y ago
    Rubygems forms an ecosystem of libraries on top of Ruby. Most gems are dev/tested within MRI, some work across other Rubies, some do not. It's difficult to tell which is which. This means most teams choose MRI in much the same way that most Ruby teams choose some form of unix -- compatibility. Ruby also suffers from the lack of a formal VM, so other implementations are merely similar rather than being guaranteed to run all programs. This is not the same with JVM vendors, where choice of IBM vs Oracle is largely based on extrinsic features rather than intrinsic compatibility. (Or at least you have to get in really deep to find differences-- in Rails you usually find incompatibilities that stop you from even starting the app).
  - coldnebo 10y ago
    Re: jruby I have considered it deeply. Many of our enterprise systems are Java-based, so JRuby's ability to call Java methods directly without implanting services would be a huge pragmatic boon. But every time I consider that I have to balance it against being able to use a constellation of gems in Rails. For example, nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, but that isn't the issue. Rather I would have to reimplement or find replacements for everything we use that depends on that without introducing side-effects. In my experience that's really hard unless it's a toy application without many dependencies. (Read: opposite of most enterprise Ruby apps) Also, as a gem author I've tried to support jruby along with MRI, but it requires jumping through a lot more hoops. Of course any cross-platform code requires more work to support, but it's a pressure on small devs. If no one needs it, no one helps support it, so then it becomes another gem that is effectively MRI-only. Kind of a viscous cycle.
    - rurounijones 10y ago
      > nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, Nokogiri natively supports JRuby, no equivalent searching required. CExts are basically the only place where this issue really pops up and all the major CExt gems (Like nokogiri) support JRuby.
- rubyfan 10y ago
  Interesting, For many years I was all in on MRI and down on JRuby but over recent years I've been quite happy with JRuby for certain things. The reality of JRuby startup times make it not a good fit for scripting tasks but otherwise server and threaded tasks are a great fit. Since using JRuby more recently I feel the ecosystem support is probably the best of the non-MRIs. I rarely run into compatibility issues. Conversely JRuby's Java integration has been a very useful feature that no other Ruby implementation offers.
magaudet 10y ago
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-sharing-java-vm-technology-with-cruby http://www.slideshare.net/MatthewGaudet/experiments-in-shari... [2]: http://rubykaigi.org/2015/presentations/MattStudies http://rubykaigi.org/2015/presentations/MattStudies

appleflaxen 10y ago

Tried looking in github, project-specific pages, wikipedia and still have no clue: What does OMR stand for? <something><something>runtime?

coldnebo 10y ago
Doesn't seem to stand for anything (at least it's not defined in the project charter). If I had to guess at it: Open Meta-Runtime But I could see how that might be misinterpreted compared to their goals. Not all cap names are acronyms? https://projects.eclipse.org/proposals/omr https://projects.eclipse.org/proposals/omr
- forkandgrok 10y ago
  It stands for Open Managed Runtime.
  - rubyfan 10y ago
    Is the Open really open, as in acceptable license that won't hold it back from gaining adoption in OSS and Enterprise community - or - are there licensing, patents or other proprietary strings attached?
    - sanxiyn 10y ago
      OMR is under Apache License. https://github.com/eclipse/omr https://github.com/eclipse/omr
magaudet 10y ago
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.

deleted 10y ago

[deleted]

skeptic2718 10y ago

I expected CPython to have something like this, especially in 3.x but nothing. If Ruby can get faster than Python sooner, I'd switch focus to Ruby (and somewhat make Go less of a priority for us).

orf 10y ago
What's wrong with PyPy?
- my123 10y ago
  Good Python 3.x support...
- progman 10y ago
  Developers who like Python syntax and want C performance should seriously consider Nim. http://nim-lang.org http://nim-lang.org
  - weberc2 10y ago
    What's the library story for Nim? Sincere question; not trying to start a flame war.
    - dagw 10y ago
      http://nim-lang.org/docs/lib.html http://nim-lang.org/docs/lib.html However many of the libraries list under "third party" are either unmaintained or not really ready for production. The stuff in the standard library seems pretty good though (although I've not used Nim for serious production work)
- brianwawok 10y ago
  It's like the bad parts of Java mixed with Python to get a little more perf
  - orf 10y ago

poorman 10y ago

"Right now, it only works for Ruby 2.1.5; however, I'm slowly plugging away at moving forward towards Ruby 2.4." The irony. But in all seriousness, this is awesome.

magaudet 10y ago
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_preliminary https://github.com/rubyomr-preview/ruby/tree/ruby_2_4_omr_pr...

deleted 10y ago

[deleted]

magaudet 10y ago

Author here: Feel free to AMA!

magaudet 10y ago
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_preliminary 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.
noahdesu 10y ago
Slightly off topic since the post is specific to Ruby, but are you able to compare OMR to Truffle and Graal?
- magaudet 10y ago
  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.
  - wgjordan 10y ago
    Related, are you aware of the JRuby+Truffle project [1]? Not a new high performance JVM language, but a high-performance implementation of Ruby using Truffle and Graal. On the surface it sounds extremely similar to Ruby+OMR (applying a high-performance, production-pedigree compiler/interpreter to an experimental Ruby implementation), so I'd be interested in hearing about any direct comparisons or knowledge-sharing between the two projects that might be possible. [1] https://github.com/jruby/jruby/wiki/Truffle https://github.com/jruby/jruby/wiki/Truffle

deleted 10y ago

[deleted]