[tiffanyh]

I really wish someone would step forward and do what Mike Pall did for Lua with LuaJIT. Phenomenal performance gains he achieved with Lua. Essentially runs equal to C performance.

And no, just because Ruby is highly dynamic - that's not an excuse for it being slow.

To quote Mike:

" tl;dr: The reason why X is slow, is because X's implementation is slow, unoptimized or untuned. Language design just influences how hard it is to make up for it. There are no excuses. "

[1] https://www.reddit.com/r/programming/comments/19gv4c/why_pyt...

[chrisseaton]

I believe that Lua is significantly simpler than Ruby. Not in the language, but in the size and scope of core library. To make a Ruby application fast you also have to make a large number of core library routines fast. A real Ruby program is not much more than a chain of core library calls.

I'm working on techniques to optimise through the core library in Ruby, and it's requiring novel research techniques that clearly weren't needed in LuaJIT, as it was done without them, so there must be something extra in Ruby.

[tiffanyh]

It might be truly that Lua is simpler but also keep in mind that LuaJIT was entirely created by a single person.

So it can be done.

And to quote Mike Pall again

"" tl;dr: The reason why X is slow, is because X's implementation is slow, unoptimized or untuned. Language design just influences how hard it is to make up for it. There are no excuses. "

[pjmlp]

Does Ruby actually do more dynamic behaviours than what is possible in Smalltalk, Lisp and Dylan?

Knowing Ruby only superficially I fail to see why the former three managed to have AOT and JIT compilers, while Ruby still requires novel research techniques as you say.

Thinking of Smalltalk, become: is probably one of the best ways to kill anything a JIT knows about an object.

[chrisseaton]

I think Ruby probably does use more dynamic behaviour in practice.

I use a Ruby library called psd.rb as an example. It's for handling Photoshop files. It represents pixels as a hash (map) of r, g and b values, and it parameterises the kind of filter in your image by making reflective method calls with dynamically created strings instead of using a function object of some kind.

So to compile that to tight machine code that looks like something a C compiler would output, you are going to have to completely optimise away the pixel hash and the reflective method call.

You could probably write that kind of code in the languages you mentioned, but people usually don't. In Ruby, that's how a lot of the code is written, starting with the standard library itself.

Maybe I could restate it by saying that optimising typical idiomatic Ruby code is more difficult than optimising typical idiomatic Smalltalk, Lisp, Lua etc.

More here: http://chrisseaton.com/rubytruffle/pushing-pixels/. Look half-way down at 'Acid Test'. My implementation of Ruby can compile that whole program to a constant.

[pjmlp]

Thanks for the overview, I was missing that.

I remembered you mentioned that example in some Graal talks I've watched.

[pselbert]

Every time there is a post regarding Ruby implementations and their speed (or lack thereof) I know there will be sobering comments from chrisseaton.

As much as I reach for more performant languages, I still need to work with Ruby on a daily basis. I really appreciate the ongoing work done by you and others to keep the ecosystem alive and prosperous.

[magaudet]

Chris is definitely an inspiration to many, myself included.