From: Bill Kelly <billk@...>
Date: 2010-09-29T22:03:03+09:00
Subject: [ruby-core:32629] Re: Proposal for Optional Static Typing for Ruby


Joshua Ballanco wrote:
> 
> It's been a while since I've taken a close look at Mirah/Duby,
> but my understanding is that the performance gains that Charles
> has achieved have less to do with static vs dynamic typing and
> much more to do with Mirah's type system being a closer match
> to Java's type system (for which the JVM is already optimized).

That's partly true - for instance by using JVM integers, one gets
the primitive native rollover at 32 bits, rather than Ruby's
seamless conversion between Fixnum<->Bignum.  So, indeed, that
involves a trade-off.

But consider Float, which is the same type as the JVM's double.

Ruby floats are allocated on Ruby's heap, just like ordinary
objects.  And Float methods like :+, :*, etc., go through
dynamic method dispatch.

By contrast, if types are known at compile time, it is common to
generate code that neither allocates floats on the heap, nor
performs dynamic dispatch on method calls, but rather generates
native machine instructions to add, multiply, etc. (or, in this
case, generates JVM opcodes which can be JIT'd to native
instructions.)

One can anticipate a couple orders of magnitude speedup in the
statically compiled version.

As an aside -- it's been pointed out to me on occasion that
dynamic languages don't theoretically have to be slow; that one
could conceivably perform sophisticated run-time analysis and
optimize certain dynamic code paths to native instructions.

But in practical terms, if types are known at compile time,
generation of efficient native code is a well understood
problem.



Regards,

Bill