Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby+OMR JIT Compiler: What’s Next?

developer.ibm.com

Post reply on HN
Print view View original

11–20 of 38 posts

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

#11

Post by rurban »

chrisseaton wrote: post #10
rurban wrote: post #9

> 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?

Nope, just one page of code. unladen swallow should have some papers, but I found out after studying their code.

Both are not working well. unladen swallow, because of incredible bloat and overhead. cperl, because it's not done yet. Just 4 days so far :) And supporting the 3 LLVM jits is awkward. I'll better decide on only one and add the llvm version as fixed requirement. MCJIT sounds best so far, when storing the jit'ed bodies for all subs in a module in extra files does not kill all the performance. v8 went without that cache, java with. With a jit cache you can easily pre-compile/warmup your stdlib and do more expensive optimizations beforehand. LLVM is really slow.

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

#12

Post by tiffanyh »

I 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 it is to make up for it. There are no excuses. "

[1] https://www.reddit.com/r/programming/comments/19gv4c/why_pyt...

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

#13

Post by chrisseaton »

tiffanyh wrote: post #12

I 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 clearly weren't needed in LuaJIT, as it was done without them, so there must be something extra in Ruby.

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

#14

Post by magaudet »

rurban wrote: post #9

> 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…

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

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

#15

Post by Twirrim »

rurban wrote: post #9

> 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

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

#16

Post by pselbert »

chrisseaton wrote: post #13
tiffanyh wrote: post #12

I 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…

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.

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

#18

Post by pjmlp »

chrisseaton wrote: post #13
tiffanyh wrote: post #12

I 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…

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.

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

#19

Post by autoreleasepool »

thatmiddleway wrote: post #4

Could this make eclim useful for ruby developers?

Eclim is already fairly useful for Ruby developers. I use it for the "stellar omnifuncs" it provides YouCompleteMe as described in the official docs [0].

[0] https://github.com/Valloric/YouCompleteMe#semantic-completio...

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

#20

Post by amaranth »

edelsohn wrote: post #17

Repurposing 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.
Post reply on HN