jcb / iteris.com (MetalOne) wrote:

> I don't know Smalltalk, but I am aware that it is interpreted and
> dynamically typed.  Thus, it has speed in the range of
> Perl/Python/Ruby.
> Ruby is purely interpreted thus on the slower end of these.
> Perl/Python/Smalltalk are translated to byte code first, and thus a
> little faster.
> LISP is interpreted and dynamically typed, but often can be compiled
> to native code.  Thus LISP can have a significant speed advantage.
> 
> Perl/Python/Ruby/Smalltalk are all so much slower than "C" though,
> that I tend to consider them to be the same.

This is a huge oversimplification.

Perl/Python/Ruby are all currently implemented using straight
interpreters, whether bytecoded or not.  Modern implementations of
Smalltalk use very sophisticated adaptive JIT compilers that can
optimize away most of the cost of method lookup, inline heavy usage of
blocks, and so on.  These are very similar to Java's HotSpot compiler,
and have similar performance (for good reason: HotSpot was derived
from Sun's Self project, which is a prototype-based Smalltalk). 
Interestingly, with this kind of JIT you get no benefit from static
type information - so the notion that Java is faster because it's
static is incorrect.

"Compiling to native code" like good lisp compilers (eg CMUCL)
wouldn't help here - for good performance with dynamic object oriented
languages, you need to be able to recompile on the fly based on
profiling the running code.  If you do that right, you can get better
performance than C++ vtables (no joke).

When I first fully realized this (after talking to Eliot Miranda,
who's responsible for the blinding speed of VisualWorks Smalltalk), it
was a minor epiphany: I don't ever have to worry that I'll be forced
into using a less dynamic language for performance reasons, because
the performance differences are illusionary.

A more reasonable statement would be "perl/python/ruby could all
*potentially* be implemented to be in the same performance range as
smalltalk (and java)".  This is almost true, although there are some
ways in which Smalltalk and Java lend themselves better to fast
implementations - the most notable is that there is a known number of
instance variables for each class, which means they can be directly
addressed rather than accessed through a lookup table.  This isn't a
show stopper, though; if someone were serious about it they could
learn from Smalltalk and Self and speed Ruby up by a couple of orders
of magnitude.

Ruby and other scripting languages have done a decent job of emulating
the dynamism of Smalltalk and Lisp; I actually think it's a bit of a
shame that the implementation techniques to make those features fast
weren't adopted as well.  Typically, however, the scripting language
answer is "if you need it to be fast, implement it in C" - whereas in
Smalltalk or Lisp the culture is to use the dynamic language all the
way down.