From: "Ryan Davis" <ryand-ruby / zenspider.com>
>
> On Oct 27, 2009, at 15:13 , Bill Kelly wrote:
>
>> Wow!  That Fibonacci example on
>> http://kenai.com/projects/duby/pages/DubySamples
>> is really neat, especially the return value inferencing.
>> I would love it if ruby had something baked-in to the language
>> that was so unobtrusive, so much like writing regular ruby,
>> but which could compile to fast static code.
> 
> You do NOT need static code for it to be fast. See smalltalk, self,  
> and many many other examples.
> 
> Ruby's method dispatch is pathologically slow.

It would certainly be the best of all possible worlds
to have ruby code run two orders of magnitude faster
without giving any hints to the compiler.

In theory, then, should it truly be possible for the
ruby compiler to generate code that keeps floating
point values in registers, performs arithmetic on them,
and then passes the resulting values off to other
methods, without ever allocating the float objects on
ruby's heap?

(Or maybe such a thing would instead be achieved at
run-time through JIT'ing and sophisticated hotspot
analysis?)

Some of the more impressive Smalltalk benchmarks I've
been able to locate so far, still hedged a bit with
the following caveats:

http://www.cincomsmalltalk.com/userblogs/buck/blogView?showComments=true&entry=3354595110

"One more note about the Integer Arithmetic benchmark.
C# is smart enough to move memory variables to registers
at the start of the method and then just perform the
arithmetic in the registers. This isn't really typical
behavior in a real system where the arithmetic operations
are scattered throughout the system. In order to make it
more fair, I made the variables into instance variables
and marked them as volatile to force C# to fetch and
write them all the time. This makes the comparison to
Smalltalk much more fair."

That seems a bit disingenuous to me.  The advent of such
in-register optimizations is what finally allowed us to
stop using the 'register' keyword in C about 15 years ago.
Now it's implied we can toss that all aside in order to be
'fair' to Smalltalk?

I'm going to have to call shenanigans on that.

But anyway, if it's truly theoretically possible to 
achieve C-like speeds in ruby without giving any hints to
the compiler then I'm all for it (obviously).

Otherwise, the remarkably unobtrusive type hinting Charlie
is experimenting with seems to me _vastly_ preferable to
the current situation of having to drop into C to get the
speed.  I don't *like* static typing.  But I like having
to drop from Ruby into C even less.

  *  *  *

I suppose the worry must be that there would be a slippery
slope, where if such static type hints existed in Ruby,
they would be overused, and we might end up with a
proliferation of third party gems and libraries which 
were decidedly un-ruby-like.

Perhaps it would be possible for the compiler to always
generate two versions of any method which was declared with
type hints: the static version, and a purely dynamic
standard ruby version.  Then such type-hinted methods would
in effect provide an optional fast-path for users who were
in need of maximum speed, without imposing any un-ruby-like
restrictions on other users?

If that were possible, would there be any downside?  (An
honest question.  I'm not thinking of any myself, so far.)


Regards,

Bill