[ruby-core:68465] Re: GSoC 2015: JIT Compiler

> Are you referring to this:
> https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List ?
> I’m not sure you'll get feedback from the responsible people on this list; maybe making a pull request is an easier way to get their attention.

You are probably right, I’ll do so. I was hoping that I can catch responsible people on ruby-core. 2-16 March Interim Period is described by Google: “Would-be students discuss project ideas with potential mentoring organizations”. And I still don’t know who represents Ruby/MRI.

> What do you mean by “all remaining 8 days?".

My reasoning was something like: If my project proposal would be “Implement a Ruby -> LuaJIT bytecode”, I’d have to prove that’s such a compilation is  possible _in_ the proposal. 8 (now 7) days are left to the start of Students Applications, so I’ll try to prove that till then.

> As for feasibility, I think the most difficult part would be to handle Ruby's blocks. I don’t think Lua has blocks, so this may be hard.

You are right. That would be easy if not that crazy procs, that can return not to the caller, but to blocks’s enclosing method! I’ll try to implement something block-like in Lua today. If that’s impossible in pure Lua, there’s still hope that generated LuaJIT bytecode can manage that, because bytecode is more powerful that the language itself.

> I am not involved in this, so I can’t give you a definitive answer, but I think it would be good to try out whether/how Ruby can be sped up by JIT compilation.

I ported a Ruby mandelbrot benchmark to Lua, using a simplified Ruby’s object model (I believe that Ruby could be compiled to the same bytecode). The speedup was 40x. I’m aware that mandelbrot generation is not actually a real-world example of Ruby code, though. And that object model is not ready. It lacks good eigenclass support.

> Maybe the goal of the project should just be to implement some JIT compilation; whether this is done from YARV to e.g. LLVM,

LLVM is heavy and doesn’t seem to be directly suitable for a JIT compiler. But it’s featured, it’s true. On the other hand, LuaJIT is a two-in-one: lighting-fast interpreter and a modern tracing JIT compiler. The only issue: it models Lua, not Ruby. I’m trying to workaround that.

> or from Ruby directly to something like LuaJIT, or from YARV to LuaJIT, could be an implementation decision by the student (together with the mentor).

That would be cool and flexible. Maybe I’ll try to write a good student proposal describing my research about LuaJIT bytecode, but with a note that an actual technology to be used can be discussed with a mentor… I’m not sure what’s the best strategy. Contact to responsible people would help so much, whoever they are.

---
Jakub Trzebiatowski
Computer science student
Gdańsk University of Technology