3 ms·

"Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler." https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-preview2-released/ http

by pella 8y ago

"Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler." https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-preview2-released/ https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-prev... -- Some benchmarks ( 2017! ) https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-organization https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-... - "Graal is too aggressive with compilations and almost always needs more CPU work than MRI interpreter" - "JRuby and Graal are the worst with memory consumption" - ...

chrisseaton 8y ago
Of course it's going to initially take more CPU work to just-in-time compile something than to just interpret it. Of course it's going to initially take more memory to just-in-time compile something than to just interpret it. Most just-in-time compilers will also include an interpreter, so yes you get the same time and space needed to run to run the interpreter, and then you get extra time and space needed to run the compiler as well. I don't really see why this would surprise anyone! You just hope that over time it pays off when you get the faster code out of the end of it, which isn't something Makarov gave them a chance to do in this post. You'll notice that when he moves beyond running micro-benchmarks, and starts to run things like OptCarrot in later posts than this and with more reasonable time for warmup, he then sees the pay off of the more sophisticated just-in-time compilers. > still the results are worse than the latest Graal Ruby https://youtu.be/emhYoI_RiOA?t=7m41s https://youtu.be/emhYoI_RiOA?t=7m41s
- pella 8y ago
  thanks for the youtube-video link!
headius 8y ago
Chris covered this pretty well, but you'll notice in my post and in the slides from my RubyC talk (https://speakerdeck.com/headius/the-year-of-jruby-rubyc-2018 https://speakerdeck.com/headius/the-year-of-jruby-rubyc-2018) I usually include CRuby + JIT from this year in the results. It rarely helps more than a few percentage points, even on numeric algorithms, so I'd say it's too early to claim anything about it.

by pella 8y ago

chrisseaton 8y ago

Of course it's going to initially take more CPU work to just-in-time compile something than to just interpret it. Of course it's going to initially take more memory to just-in-time compile something than to just interpret it. Most just-in-time compilers will also include an interpreter, so yes you get the same time and space needed to run to run the interpreter, and then you get extra time and space needed to run the compiler as well. I don't really see why this would surprise anyone! You just hope that over time it pays off when you get the faster code out of the end of it, which isn't something Makarov gave them a chance to do in this post. You'll notice that when he moves beyond running micro-benchmarks, and starts to run things like OptCarrot in later posts than this and with more reasonable time for warmup, he then sees the pay off of the more sophisticated just-in-time compilers. > still the results are worse than the latest Graal Ruby https://youtu.be/emhYoI_RiOA?t=7m41s https://youtu.be/emhYoI_RiOA?t=7m41s

pella 8y ago
thanks for the youtube-video link!

headius 8y ago

Chris covered this pretty well, but you'll notice in my post and in the slides from my RubyC talk (https://speakerdeck.com/headius/the-year-of-jruby-rubyc-2018 https://speakerdeck.com/headius/the-year-of-jruby-rubyc-2018) I usually include CRuby + JIT from this year in the results. It rarely helps more than a few percentage points, even on numeric algorithms, so I'd say it's too early to claim anything about it.