Ruby 3x3 is here already. It's called Elixir ;)
No, seriously, if your heart beats for Ruby, you will fall in love with Elixir. Give it a try and you won't look back.
Ruby+OMR JIT Compiler: What’s Next?
21–30 of 38 posts
Re: Ruby+OMR JIT Compiler: What’s Next?
#22Earlier quoted context omitted.
I believe that Lua is significantly simpler than Ruby. Not in the language, but in the size and scope of core library. To make a Ruby application fast you also have to make a large number of core library routines fast. A real Ruby program is not much more than a chain of core library calls. I'm working on techniques to optimise through the core library in Ruby, and it's requiring novel research techniques that clearl…
Does Ruby actually do more dynamic behaviours than what is possible in Smalltalk, Lisp and Dylan? Knowing Ruby only superficially I fail to see why the former three managed to have AOT and JIT compilers, while Ruby still requires novel research techniques as you say. Thinking of Smalltalk, become: is probably one of the best ways to kill anything a JIT knows about an object.
I think Ruby probably does use more dynamic behaviour in practice.
I use a Ruby library called psd.rb as an example. It's for handling Photoshop files. It represents pixels as a hash (map) of r, g and b values, and it parameterises the kind of filter in your image by making reflective method calls with dynamically created strings instead of using a function object of some kind.
So to compile that to tight machine code that looks like something a C compiler would output, you are going to have to completely optimise away the pixel hash and the reflective method call.
You could probably write that kind of code in the languages you mentioned, but people usually don't. In Ruby, that's how a lot of the code is written, starting with the standard library itself.
Maybe I could restate it by saying that optimising typical idiomatic Ruby code is more difficult than optimising typical idiomatic Smalltalk, Lisp, Lua etc.
More here: http://chrisseaton.com/rubytruffle/pushing-pixels/. Look half-way down at 'Acid Test'. My implementation of Ruby can compile that whole program to a constant.
Re: Ruby+OMR JIT Compiler: What’s Next?
#23Repurposing a statically-typed JIT is limiting. This is why PyPy, v8, LuaJIT and HHVM all have written custom JITs specifically for the languages. https://pdfs.semanticscholar.org/d1fc/e50f5476088671adc3910d...
I'm pretty sure that paper is talking about an earlier version of this same work targeting Python instead of Ruby.
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.
Re: Ruby+OMR JIT Compiler: What’s Next?
#24> In Evan’s keynote, he proposed a really interesting and ambitious solution to the problem he called “lifting the core.” It involved shipping Ruby with LLVM intermediate representation of the CRuby functions to allow the LLVM JIT technology to look inside the CRuby functions and dramatically increase the optimization horizon. As far as I know, this hasn’t been attempted yet — although, if it has, I really want to se…
Wow I had no idea anyone was shipping bitcode of their runtime for dynamic compilation. Are there any blog posts, papers, etc about it? Does it work well?
impala does.
Re: Ruby+OMR JIT Compiler: What’s Next?
#25Earlier quoted context omitted.
Wow I had no idea anyone was shipping bitcode of their runtime for dynamic compilation. Are there any blog posts, papers, etc about it? Does it work well?
impala does.
For those curious about background: https://blog.cloudera.com/blog/2013/02/inside-cloudera-impal...
Re: Ruby+OMR JIT Compiler: What’s Next?
#26Earlier quoted context omitted.
I believe that Lua is significantly simpler than Ruby. Not in the language, but in the size and scope of core library. To make a Ruby application fast you also have to make a large number of core library routines fast. A real Ruby program is not much more than a chain of core library calls. I'm working on techniques to optimise through the core library in Ruby, and it's requiring novel research techniques that clearl…
Every time there is a post regarding Ruby implementations and their speed (or lack thereof) I know there will be sobering comments from chrisseaton. As much as I reach for more performant languages, I still need to work with Ruby on a daily basis. I really appreciate the ongoing work done by you and others to keep the ecosystem alive and prosperous.
Chris is definitely an inspiration to many, myself included.
Re: Ruby+OMR JIT Compiler: What’s Next?
#27Ruby 3x3 is here already. It's called Elixir ;) No, seriously, if your heart beats for Ruby, you will fall in love with Elixir. Give it a try and you won't look back.
I really like Elixir... but to say it's ruby 3x3 isn't quite fair. While the syntax is ruby-like, even the simplest ruby program isn't directly portable to Elixir. It's definitely something different, so saying things like this is misleading.
It'd be closer to say: > Ruby 3x3 is here already. It's called Crystal ;)
Definitely check out Elixir and Crystal though if you need more performance.
Re: Ruby+OMR JIT Compiler: What’s Next?
#28Earlier quoted context omitted.
Does Ruby actually do more dynamic behaviours than what is possible in Smalltalk, Lisp and Dylan? Knowing Ruby only superficially I fail to see why the former three managed to have AOT and JIT compilers, while Ruby still requires novel research techniques as you say. Thinking of Smalltalk, become: is probably one of the best ways to kill anything a JIT knows about an object.
I think Ruby probably does use more dynamic behaviour in practice. I use a Ruby library called psd.rb as an example. It's for handling Photoshop files. It represents pixels as a hash (map) of r, g and b values, and it parameterises the kind of filter in your image by making reflective method calls with dynamically created strings instead of using a function object of some kind. So to compile that to tight machine cod…
Thanks for the overview, I was missing that.
I remembered you mentioned that example in some Graal talks I've watched.
Re: Ruby+OMR JIT Compiler: What’s Next?
#29Repurposing a statically-typed JIT is limiting. This is why PyPy, v8, LuaJIT and HHVM all have written custom JITs specifically for the languages. https://pdfs.semanticscholar.org/d1fc/e50f5476088671adc3910d...
Sorry David, but I need to speak against this 5 year old paper of yours.
I strongly disagree (and always have) with your statement that repurposing a statically typed JIT is limiting. The JIT projects you mention get lots of their performance from profile data which essentially presents type guesses so the compiler can speculatively optimize and recover when that info is wrong. Guess what? That's what statically typed Java JIT compilers do too, and the OMR compiler is no different, though we haven't sunk all that capability to OMR from Testarossa just yet (it's coming!).
I would be a lot happier with you repeating, or at least not propagating specifically the opposite conclusion, this line from your own paper:
On page 16, under Conclusion: "Our point, however, is not to argue against the repurposing of JIT compilers, but to define guiding principles and to promote techniques to construct an effective RJIT compiler."
Since this article was written, the entire Testarossa code base has been substantially refactored and parts of it rewritten (by the production Testarossa team) and streamlined to make it more amenable to dynamic optimization of other languages. We haven't finished that process (there's still more stuff we need to pull into the OMR compiler technology), but I really think your provocative statement above promotes a very broad conclusion from a research project that unfairly tries to close the door on what I still believe is a very reasonable technology evolution path. Especially since the article's conclusion is based on one research project for one language and one runtime where IMO the most reasonable conclusion is that just adding a JIT to an existing runtime is not enough to compete with a project that rewrote the entire runtime. That doesn't mean existing runtimes have nothing but bespoke paths forward or that reusable JIT technology cannot play a substantial part in that runtime's future evolution.
Finally, note that the OMR technology is being used (commits pulled in on an hourly basis) to build the production J9 JVM, which is also slated to be open sourced this year. There are also projects to use OMR for Ruby (see original post :) ), Lua, Rosie, Smalltalk (SOM++), Javascript, Python (currently inactive), and a runtime for workshops called Base9. I can provide links for the ones that have been open sourced already if people can't find them on github.
For those kind enough to have read to the end of this response (thank you!), please know that we have proposed several GSoC projects [1] to port to other languages and we're pretty open minded and positive about the potential and possibilities of reusing the Eclipse OMR compiler and other runtime components. Feel free to suggest alternative projects if you have a particular area of interest since we have lots of interested mentors available!
[1] https://wiki.eclipse.org/Google_Summer_of_Code_2017_Ideas#Ec...
Re: Ruby+OMR JIT Compiler: What’s Next?
#30I really wish someone would step forward and do what Mike Pall did for Lua with LuaJIT. Phenomenal performance gains he achieved with Lua. Essentially runs equal to C performance. And no, just because Ruby is highly dynamic - that's not an excuse for it being slow. To quote Mike: " tl;dr: The reason why X is slow, is because X's implementation is slow, unoptimized or untuned. Language design just influences how hard…
I believe that Lua is significantly simpler than Ruby. Not in the language, but in the size and scope of core library. To make a Ruby application fast you also have to make a large number of core library routines fast. A real Ruby program is not much more than a chain of core library calls. I'm working on techniques to optimise through the core library in Ruby, and it's requiring novel research techniques that clearl…
It might be truly that Lua is simpler but also keep in mind that LuaJIT was entirely created by a single person.
So it can be done.
And to quote Mike Pall again
"" tl;dr: The reason why X is slow, is because X's implementation is slow, unoptimized or untuned. Language design just influences how hard it is to make up for it. There are no excuses. "