Don't count on Ruby getting 10x faster anytime soon. The meta-object model and method-missing reliance of many of the libraries make performance optimizations of JITs a very limited enterprise.
While your work is very impressive, and I'm a big fan of Graal and systems like it, I think it's a mistake to say that something is solved when there's a single research system that gets good performance. As another example, there have been systems with fast continuations for 40 years, but I still wouldn't call that solved. I've built a JIT that's very effective at optimizing contracts, but I don't think that's solved either.
Well the statement was that it was not possible to remove the overhead of method_missing (well they didn't actually say 'impossible' but that's how I read it, and I also took them to be referring to peak performance, because people usually are).
I solved the problem of showing that it is possible to do that. Before people thought it was impossible, and now they know it isn't.
I'm not claiming I solved other problems such as removing the overhead with low memory or removing it in corner cases.
I hear the Truffle+Graal combination is getting very good results about Ruby. Here is video about it (pointed to the missing-method example): [1]
They're hitting 35x in some benchmarks [2]. Most benefits being in workloads where Ruby has to continuously talk to C; the result-passing part gets compiled away.
It is available in Java 9, if I'm not mistaken. LLVM IR bytecode ingestion is in preparations too [3].
Three of the biggest Rails Shop, ( this is assuming the most popular, resources heavy usage are Rails related. ) all run on CRuby. That is Cookpad, Shopify, and GitHub. ( Basecamp in rather small compared to these 3 )
I wonder if there are any popular webshop ran on JRuby, or why those three dont use JRuby.
It's true that many libraries would perform poorly because of a reliance on method_missing. But what can be made quite fast is code that either uses define_method instead, or uses define_method on the first failed call.
In fact, a tracing jit could even make the method_missing case fast by automatically specialising and optimizing missing coupled with a vtable/dispatch table.
My forever-in-progress ahead-of-time Ruby compiler uses vtable based dispatch for every method name that's seen in the program at least once, and that's usually most of them (unless people e.g. construct method names dynamically at runtime).
To handle method_missing, it creates thunks for each method name and fills the missing vtable slots with those, which is similar to what I suggest above - the next step of dynamically optimising method_missing for called symbols and replacing the vtable thunks would be a relatively minor step in a JIT.
I don't think anyone expects Ruby to get dramatically faster in the very short term, but there's lots of opportunity to make most Ruby code much faster in the medium term.
I think we'll also start seeing implementations that do things like JIT influence how people write Ruby, because a lot of things won't matter much for MRI performance but will be a huge deal for implementations that uses compilation techniques, so it's possible to get a lot more "compiler-friendly" Ruby while still writing clean Ruby that runs well on other implementations.
e.g. the above "define_method on method_missing" basically boils down to (pseudo code):
def method_missing sym, *args
raise suitable exception if sym doesn't meet right criteria
define_method(sym, args...) do
... whatever ..
end
send(sym,*args)
end
If it lets an implementation speed up its (ab)use of method_missing enough, you'll see people adopt stuff like that.
Smalltalk has those same features (which is where Ruby got them from). Almost all of the high performance JIT technology we use these days was originally invented by Smalltalk VM hackers. They invented that stuff specifically to make that kind of code go fast.
The 3x was compared to Ruby 2.0, on some slides they claim Ruby 2.4 is already 30 - 40% faster then 2.0, so effectively you will only get around 2x more speedup.
Java with Ruby's syntax and undeclared typing would make Java programs so shorter that it would be worth it. But there would be nothing left of Java, except the object orientation. It would just be a simpler more static Ruby.
No because it's statically typed, too much work programming like that and it's not worth it for the kind of software I develop (backend of web/mobile apps), but thanks. Suggestions are always appreciated.
It's object oriented and runs on the top of the Erlang VM. It maps classes on gen servers, which is pretty natural and it spares the developer all the boilerplate of creating a gen server module. Unfortunately the language designer killed it because "it's pretty bad to have two competing niche languages with nearly identical features." The other language was Elixir. However the two languages are very different. Elixir is 100% functional, Reia could have been the language to transition millions of OO developers to a functional and concurrent world. I could have used it instead of Ruby.
This is an odd stance. Backends are where static typing shine, and where those who like static typing sing its praises. Maybe you just don't like static typing?
I really don't find static typing to be more "work". You still have to think about types in dynamically typed languages, you just get to skip specifying them.
There are other ways of meta programming that are still performant.... that is why many Ruby devs see Elixir/beam and Clojure/jvm as good language/platform alternatives.
If you don't mind starting from scratch and using a statically typed language, crystal is amazing. However, you will not get vary far porting any large ruby project to crystal without a rewrite from scratch.
However many of the libraries list under "third party" are either unmaintained or not really ready for production. The stuff in the standard library seems pretty good though (although I've not used Nim for serious production work)
Except it's nothing like that, it's like an interpreter framework written in Python with a reference implementation that happens to be a Python interpreter. Write your interpreter in RPython, use the right decorators and boom you have a compiled interpreter with a free JIT (with speeds that beat C in some workloads, apparently).