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.
> Any web request in my rails app could theoretically add new functions to any other class
Java Spring applications pretty much do the same thing (reflections, proxy beans, aop, JSON/Date serializers/deserializers, ORMs, etc are all compiled and changed dynamically upon route hits).
These things are theoretically possible (and happen) in any JIT language (node, java). Only statically compiled languages seems to be immune to this.
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.
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
They asked if it could be "as fast as the JVM", which JIT is a crucial part of how the JVM achieves its performance. JIT in this context is referring to the process of a source file (.rb, .js, .c, etc), or usually bytecode, being compiled into machine code. I cannot think of an instance where a C source file is JIT compiled and dlopen(3) will not be happy if you tried to call it on a C source file.
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.
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.
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.
> Any web request in my rails app could theoretically add new functions to any other class
Java Spring applications pretty much do the same thing (reflections, proxy beans, aop, JSON/Date serializers/deserializers, ORMs, etc are all compiled and changed dynamically upon route hits).
These things are theoretically possible (and happen) in any JIT language (node, java). Only statically compiled languages seems to be immune to this.
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.
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
They asked if it could be "as fast as the JVM", which JIT is a crucial part of how the JVM achieves its performance. JIT in this context is referring to the process of a source file (.rb, .js, .c, etc), or usually bytecode, being compiled into machine code. I cannot think of an instance where a C source file is JIT compiled and dlopen(3) will not be happy if you tried to call it on a C source file.
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.
Ruby can run on the JVM...
Will Ruby ever be as fast as Java? Probably not, because Ruby is dynamic (don't know types until runtime) and Java is static...
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!)
You could use Ruby on top of JVM such as TruffleRuby and JRuby.