bryce at kampjes.demon.co.uk wrote:
> There's many reasons why there isn't a larger gain. One is only a few
> methods are being compiled.

Why not compile everything to see what the baseline gain is? This is 
really the number I'm interested in - compile the entire image, and run 
the macro benchmarks and compare that. And not only would it be a good 
stress-test but for some applications (like our Croquet servers) that 
would be entirely reasonable; even desirable.

Cheers,
   - Andreas

> The problem I'm working on now is the stack is being loaded into
> registers when Exupery enters a context then saved back into the
> context when it leaves. This is particularly inefficient if the
> registers get spilled to the C stack as then they're copied into
> registers to be immediately copied to memory at a different location.
> This makes real case sends potentially worse than the send benchmark.
> 
> With earlier benchmarks compilation was slowing down object allocation
> because allocation is inlined into the main interpreter loop but
> Exupery was doing a full worst case send to get to the primitive. (1)
> 
> To benefit from PICs both the sending and receiving methods must be
> compiled. That may not be happening as much as it should be. This can
> be blocked by some of the few missing bytecodes. Stack duplication is
> the only serious missing bytecode.
> 
> The generated code is relatively sloppy still. Exupery doesn't handle
> SIB byte addressing modes so it can't access literal indirections
> which are used heavily to access interpreter state. Temporaries are
> not stored in registers, that's until after the stack register
> improvements are finished.
> 
> The visible progress since the last release is the compiler benchmark
> now shows a 10% gain and compiling interpretExtension:in:for: is about
> 9 times faster.
> 
> Bryce
> 
> (1) It wasn't creating the context but it was going through the PIC
> then dropping into a helper method which ran through the interpreter's
> send code. 
> 
>