bryce at kampjes.demon.co.uk wrote:
> Andreas Raab writes:
> 
>  > One of my problems with Exupery is that I've only seen claims about byte 
>  > code speed and if you know where the time goes in a real-life 
>  > environment then you know it ain't bytecodes. In other words, it seems 
>  > to me that Exupery is optimizing the least significant portion of the 
>  > VM. I'd be rather more impressed if it did double the send speed.
> 
> Then be impressed. Exupery has had double Squeak's send performance
> since March 2005.
> 
>  http://people.squeakfoundation.org/person/willembryce/diary.html?start=23

That's pretty impressive.

> That's done by using polymorphic inline caches which are also used to
> drive dynamic primitive inlining. It is true that further send
> performance gains are not planned before 1.0. Doubling send
> performance should be enough to provide a practical performance
> improvement. It's better to solve all the problems standing in the way
> of a practical performance improvement before starting work on full
> method inlining which should provide serious send performance.

Indeed. So what's in the way of practical performance improvement at 
this point? I was quite surprised that in your corrected benchmarks the 
two that were macros wouldn't show any improvement:
   bytecodeBenchmark       2111 compiled  460 ratio:  4.589
   sendBenchmark           1637 compiled  668 ratio:  2.451
   [...]
   largeExplorers           728 compiled  715 ratio:  1.018
   compilerBenchmark        483 compiled  489 ratio:  0.988

With sends 2.5x faster I would expect *some* noticable improvement. Any 
ideas what the problem is?

Cheers,
   - Andreas