Peter Suk wrote:
> On Apr 8, 2005, at 4:41 AM, flaig / sanctacaris.net wrote:
>
> > Yeah, I'm curious about that too... a couple of years ago I wrote a

> > Python-2-native compiler but was very disappointed to find that it
> > revved up things only 2x to 3x (to less than 1/10 the speed of C
> > code), the matter obviously being that Python's way of object
handling
> > already consumed most of the CPU time.
>
> Reference counting GC, isn't it?  That automatically raises your
> assignment overhead 2X.

and breaks all existing extensions, unless you have special compiler
support.

> >  Obviously, the need for endless type checks, comparisons and
> > conversions, not to mention memory allocation and deallocation, is
a
> > bottleneck, at least in Python -- and though I am not really
familiar
> > with the internals of the Ruby interpreter, I think that the
problem
> > will be pretty much the same. Also in Smalltalk.
>
> Generational GC.  (So you're not at the mercy of the system's malloc
&
> free)

A generational GC would be great.  There has been talk of including one
in the next version of the Ruby interpreter.  However C extensions also
pose a problem here as well - it seems creating a write barrier that
works with C libraries not written originally with Ruby in mind will be
very difficult/slow.

-Charlie

> JIT.  Implementing message sends as direct jumps for monomorphic
> methods.  (& polymorphic methods with a caching strategy.)  Call
chain
> optimization.  Those are the ones I know about.  Not all Smalltalks
use
> them.
>
> > So there must really be some fundamental stroke of genius
involved....
> > And if so, what about incorporating this into Ruby 2.x one day? :-)
>
> As far as I am concerned, this project is a rehearsal for the
> appearance of Ruby 2.x.
>
> --Peter
>
>
> --
> There's neither heaven nor hell, save what we grant ourselves.
> There's neither fairness nor justice, save what we grant each other.