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.
It's not Ruby if it doesn't run Rails.
Ruby+OMR JIT Compiler: What’s Next?
31–38 of 38 posts
Re: Ruby+OMR JIT Compiler: What’s Next?
#32Ruby 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.
> No, seriously, if your heart beats for Ruby, you will fall in love with Elixir.
I like Ruby, I like Elixir, but the latter for basically none of the same reasons as the former.
Re: Ruby+OMR JIT Compiler: What’s Next?
#33Ruby 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 understand that you're an Elixir enthusiast, you probably feel like people have not yet seen the light and they need to be educated about superior alternatives, but two things about that:
1) It borders on proselytizing and it's annoying to see people coming over to preach the good word on every other Ruby article. If your language of choice has merits, it doesn't need hype men, people will use it naturally.
2) Elixir is not Ruby, stop trying to sell it as such. They're two completely different languages. That one has heavily influenced the other's syntax choices is merely a sign that the language author liked what he found in Ruby before creating Elixir.
Re: Ruby+OMR JIT Compiler: What’s Next?
#34> 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…
On the GNU side there is https://www.gnu.org/software/libjit/ that could presumably be used, but that's GPLv3 and would have consequences
Na, all those abstract jit libraries suck. They are too abstract and thereby failed to support the needed architectures.
Practically usable are only LLVM and dynasm.
Now the orm guys did something special I appreciate a lot. Basically they re-invented parrot, with a proper, fast object system with compile-time class extensions in C++, plus still supporting run-time inheritance via vtables. And on top of their existing stable jit engine for java, they started targeting ruby and python (unofficially).
Much better than parrot (which I'm maintaining on life-support), and probably also better than rpython. We will see how this will turn out, as they already have truffle, which don't like that much. orm looks much better to me.
Re: Ruby+OMR JIT Compiler: What’s Next?
#35Earlier quoted context omitted.
On the GNU side there is https://www.gnu.org/software/libjit/ that could presumably be used, but that's GPLv3 and would have consequences
Na, all those abstract jit libraries suck. They are too abstract and thereby failed to support the needed architectures. Practically usable are only LLVM and dynasm. Now the orm guys did something special I appreciate a lot. Basically they re-invented parrot, with a proper, fast object system with compile-time class extensions in C++, plus still supporting run-time inheritance via vtables. And on top of their existin…
Yes, libraries like libjit help you to emit a low level program, but that was never the problem anyone had.
The problem is turning Ruby into a low level program in the first place.
Re: Ruby+OMR JIT Compiler: What’s Next?
#36Earlier 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.
The impala bitcode reader/resolver is here: https://github.com/cloudera/Impala/blob/cdh5-trunk/be/src/co...
It also needs a special mcjit resolver: https://github.com/cloudera/Impala/blob/cdh5-trunk/be/src/co...
Re: Ruby+OMR JIT Compiler: What’s Next?
#37What does OMR stand for? Couldn't easily find a definition for it.
Re: Ruby+OMR JIT Compiler: What’s Next?
#38What does OMR stand for? Couldn't easily find a definition for it.
OMR is the Open Managed Runtime. Basically, IBM took their Java implementation (the J9 JDK), or more precisely, J9's Java Virtual Machine implementation, separated all the language-specific and VM-specific parts from the language-agnostic and VM-agnostic parts, broke it up into independently re-usable modules (memory manager, JIT compiler, garbage collector, profiler, debugger) and released it as Open Source Software under the umbrella of the Eclipse Foundation.
Ruby+OMR is the proof-of-concept project that aims to show that OMR is indeed language-agnostic and VM-agnostic and can be used as drop-in parts not only for newly-designed VMs but also easily integrated into existing VMs. The Java 8 version of IBM's J9 JDK is already built on top of OMR, but you could consider that cheating, since that's the very VM OMR came out of; Ruby+OMR shows that you can also do that with languages other than Java and VMs that have a different design than J9.
I believe there is also a Python+OMR project which does similar things with the CPython VM, but that project is not (yet) public, AFAIK.