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.
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.
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 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.
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.
I believe most browser JS runtimes do it too.
I wonder if Ruby's VM will ever become as fast as the JVM
Short answer: no.
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.
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.
Even V8 isn't as fast as JVM :) I think only LuaJIT is comparable in some ways.
Are you aware of jruby?
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!)