Göran Krampe wrote on Thu, 18 May 2006 10:55:58 +0200
> Hans-Martin Mosner wrote:
> > tim Rowledge wrote:
> > > Compiling straight to machine code is certainly doable; it simply  
> > > involves a lot more work since you have to develop and optimise and  
> > > debug a *lot* more stuff. For example, you'd have to rewrite the  
> > > compiler, the debugger, the InstructionStream related classes and  
> > > tools, any system that expects to write out methods, etc etc. Send  
> > > enough money and I will arrange it for you. Discussions could start  
> > > at, ooh, One *Million* Euros.
> > 
> > Doable, but not really a good way to implement Smalltalk.
> 
> And so what do you guys think of Exupery? I had the distinct impression
> that Exupery is exactly this (a sophisticated machine code compiler for
> Smalltalk) - and as long as Exupery can mop the floor with the regular
> VM performance wise - then why would it be "not really a good way"?

Exupery translates bytecodes to x86 (for now) machine code, so it is
like the alternative Hans-Martin mentioned instead of the solution Tim
said wasn't a good idea.

The SOAR (Smalltalk On A RISC) project at Berkeley did actually
translate directly to machine code and skipped the bytecodes altogether
and one of the lessons learned was that it wasted memory and didn't gain
any speed compared to the dynamic translation alternative. Smalltalk X
also started as a pure translations system (to C rather than directly to
machine code) and later added bytecodes to the mix to make interactive
use faster. Smalltalk MT is, as far as I know, a bytecodeless system.

Sebastián Sastre wrote:
>	I think this technology is feasible with a considerable effort. More
> than that I saw a little *proof of concept* of this idea based on a largely
> modified squeak image. To give you an idea that limted prototype makes sends
> about x54 times than Exuperys do. And please don't get me wrong, I do like
> Exupery, but I think we could get a lot longer than that.

The only way I can see that a "limited prototype" could make sends
faster than what Exupery does is by extensively inlining code, and that
is something which future versions of Exupery will have as well (it has
been on the roadmap since the beginning). If you have any more
information about this, I would love to see it.

As we saw in Self, when combined with other optimizations inlining can
actually make sends take a negative number of clock cycles as measured
by benchmarks! Trying to match that with a hardware solution (like the
ones I build) is, obviously, not possible.

-- Jecel