|
|
|
|
|
|
by pjmlp
3396 days ago
|
|
|
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. |
|
|
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.