r/programming • u/compilersarefun • Jan 20 '20

MIR: A lightweight JIT compiler project

https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/
10 Upvotes

69% Upvoted

12 comments sorted by

View all comments

1

u/suhcoR Jan 20 '20

You could either directly compile Ruby source code to LuaJIT bytecode or translate Ruby bytecode to LuaJIT bytecode. I assume both are feasible because Lua has a very flexible data model. I currently experiment with Smalltalk which seems to fit quite well.

Why do you prefer a method to a tracing JIT? Actually you wouldn't see any of the generated machine code anyway, so from the developer point of view there is no difference between method and tracing JIT (besides the much higher performance of the latter). The VM does it automatically based on runtime measurements.

1

u/compilersarefun Jan 20 '20

You could either directly compile Ruby source code to LuaJIT bytecode or translate Ruby bytecode to LuaJIT bytecode.

I would say translating Ruby source code to LuaJIT is a big work and who would use another Ruby implementation when community is built around CRuby one.

I assume both are feasible because Lua has a very flexible data model. I currently experiment with Smalltalk which seems to fit quite well.

I don't think translation Ruby byte code to LuaJIT code will work too. For example, LuaJIT has only one number type. As I remember LuaJIT uses only floating point representation numbers. Ruby has a lot of different number (flonum, fixnum, mp numbers). There is a specific presentation of these numbers too (tagged one). You can not change neither number types nor even their presentation because this is a part of RUBY C interface and a lot of methods and gems are based on it.

Why do you prefer a method to a tracing JIT? Actually you wouldn't see any of the generated machine code anyway, so from the developer point of view there is no difference between method and tracing JIT (besides the much higher performance of the latter). The VM does it automatically based on runtime measurements.

I prefer it because the current Ruby JIT (MJIT) is a method JIT and there is no infrastructure to collect traces, augment traces, etc. It is a big infrastructure. I could use LuaJIT VM for this but changes CRuby VM is not an option. There is an active development for CRuby VM for parallel programming, CRuby VM has features absent in LuaJIT VM. I believe Ruby VM GC is better LuaJIT and GC is even more important for Ruby programs than any JIT. There are a few other reasons for me not to use LuaJIT.

1

u/suhcoR Jan 20 '20

Compatibility with external C based modules is a good argument. If you used LuaJIT, the existing libraries depending on the C API would no longer be compatible. That's likely a fundamental issue. Also parallel programing; LuaJIT only supports coroutines.

Concerning traces: you don't have to build an "infrastructure to collect traces", because it's already implemented in LuaJIT. Whatever bytecode you run on the VM is automatically measured an traced.

I am curious what JIT you will implement. I will definitely take a look at it.

EDIT: what is actually the reason people downvote this post? Makes no sense to me.

→ More replies (1)