Exupery is finally faster than VisualWorks for the bytecode
benchmark. There is still plenty of room to tune Exupery's bytecode
performance. It's major advantage is it uses a colouring coalescing
register allocator.

For Exupery running in Squeak:
 '694,237,288 bytecodes/sec; 14,295,065 sends/sec'

For the Squeak interpreter:
 '204146730 bytecodes/sec; 6390893 sends/sec'

For VisualWorks:
 '687,248,322 bytecodes/sec; 82,031,109 sends/sec'

And my standard benchmarks comparing the interpreter to Exupery.
 Benchmark		   Interpreter	 Exupery      Ratio
 arithmaticLoopBenchmark   1595 compiled  132  ratio: 12.083
 bytecodeBenchmark	   2459 compiled  715  ratio:  3.439
 sendBenchmark		   1776 compiled  816  ratio:  2.176
 gifConversion		   2042 compiled 1565  ratio:  1.305
 Cumulative Time	   1942 compiled  589  ratio:  3.296

It's still a lot slower than VisualWorks for sends but it it twice
as fast as the interpreter.

The plan is to rewrite the at: and at:put: implementation next. I'm
going to use PICs to type check then compile a specialised version of
at: for each receiver. This may make at: slower in the short term, I
don't know. But it will mean that optimising at: will also optimise
sends in general. And it will provide the machinery to optimise other
critical primitives such as new:.

After that I'm planning on improving Exupery's general reliability.

The key question is what is the absolute minimum that needs to be done
to make Exupery practically useful. There are plenty of largish
projects that could make Exupery much faster, but being useful is
important too.

Bryce