It’s hard to generate efficient code ahead-of-time because the compiler doesn’t know what the types of values will be, so it has to emit very general code that can cope with all possibilities at the expense of performance. A just-in-time compiler has access to this type information because it’s executing at runtime, so it’s able to generate more efficient code which only works in the more specific situation that is actually happening right then.

See Natalie [0] for a work-in-progress Ruby compiler which works ahead of time. It’s a super cool project but it’s just for fun [1] so I don’t believe it’s trying to compete on performance.

[0] https://natalie-lang.org/

[1] https://justforfunnoreally.dev/

JIT VMs often rely on runtime tracing to form assumptions about a program, and then JIT native code that fits those assumptions. If/when those assumptions break, the VM can fall back to interpreting the original code.

That means there is no need to write a fully-featured Ruby compiler, instead you only have to emit native code in places/situations where it will have the maximum benefit.