I wonder if there's ever a point at which you could run a thread at very low "niceness" that just slowly keeps compiling more and more methods into native code as the program goes on. Surely this would be worth it for long lived server programs. You could even keep it around to periodically recompile methods if runtime information shows that some paths are hotter than others.
One reason is that the JIT needs info on the types passed to the method, which are only available after a few calls. Per the article, a+b could refer to any type of a and b. The only way to know what was used is profiling.
The article targets MRI (Matzes Ruby Interpreter). It does not execute threads concurrently. Probably for the same reason that Python imposes limits on threads - to stay single threaded when calling into C libraries, most of which were written before threads were important enough to think about them
While that's true for the running program, it doesn't stop the JIT engine running a thread to compile code as the parent comment suggested. It's not running the ruby code.
This technique is used by some existing VMs. .NET does this with a background thread and calls it 'tiered compilation', where methods are queued for recompilation at a higher (more expensive/thorough) optimization level in the background. It's pretty helpful.
Slightly longer answer: no, because Ruby as a language isn't designed to be JIT friendly. Any web request in my rails app could theoretically add new functions to any other class, in ways that would just not work in most other languages. This wreaks havoc on JIT compilers, because they constantly need to check if the assumptions they made when compiling certain bits of code still hold or if the entire world has shifted out from underneath them. This is a super beloved aspect of Ruby, but is just not JIT friendly.
I don’t think that answers GPs question. They asked it could be fast (a result), not if it could use a JIT (an implementation detail). I would argue it is an easy language to JIT since its semantics are clear and straightforward, just that it might not gain any speed if there aren’t any optimizations it can apply over the code run in the JIT.
If you want an example of a bad language to JIT, take C for example, where parsing and running code is hugely context dependent and adding new code can change just about anything about the existing code without anything knowing about it. And yet most C runs via a JIT: dlopen, the just in time loader. Just look at the mess that is historic ELF to attempt to deal with the problem
While it's true that CAN happen, it doesn't mean it happens often enough to disrupt JIT compiling the code. It does mean there is an invalidation when code paths are modified.
JRuby is a thing and it runs on the JVM as more than a simple interpreter. The JVM does have to deal with this exact problem. So you could actually say Ruby can already run as fast as the JVM because it runs on it, what it cannot do is run as fast as a static language because, at the very least, it has to deal with additional checks that things haven't changed.
Something that might be useful would be a sub language that didn’t support all the dynamic features that make JIT difficult or slow. Perhaps a module could have a pragma or something to indicate the language set in use. Maybe like Racket. Simply not being able to add new methods or new member variables after initialization would help.
It is ruby running on a Java Virtual Machine. Imposes all downsides of the JVM (try to allocate more that 4GByte per object!) and provides JVMs concurrency model. Currently supports Ruby 3.1 (it claims to support 3.4, read the fine print if your specific feature is supported!)
I believe most browser JS runtimes do it too.
Slightly longer answer: no, because Ruby as a language isn't designed to be JIT friendly. Any web request in my rails app could theoretically add new functions to any other class, in ways that would just not work in most other languages. This wreaks havoc on JIT compilers, because they constantly need to check if the assumptions they made when compiling certain bits of code still hold or if the entire world has shifted out from underneath them. This is a super beloved aspect of Ruby, but is just not JIT friendly.
If you want an example of a bad language to JIT, take C for example, where parsing and running code is hugely context dependent and adding new code can change just about anything about the existing code without anything knowing about it. And yet most C runs via a JIT: dlopen, the just in time loader. Just look at the mess that is historic ELF to attempt to deal with the problem
JRuby is a thing and it runs on the JVM as more than a simple interpreter. The JVM does have to deal with this exact problem. So you could actually say Ruby can already run as fast as the JVM because it runs on it, what it cannot do is run as fast as a static language because, at the very least, it has to deal with additional checks that things haven't changed.
https://www.jruby.org/
It is ruby running on a Java Virtual Machine. Imposes all downsides of the JVM (try to allocate more that 4GByte per object!) and provides JVMs concurrency model. Currently supports Ruby 3.1 (it claims to support 3.4, read the fine print if your specific feature is supported!)