Is it worth releasing now?

[bryce at kampjes.demon.co.uk]

Exupery now produces a noticeable speed improvement for the compiler
benchmark. This is the bytecode compiler. I'm now going to work on
reliability. It's probably more reliable now than the last release.

arithmaticLoopBenchmark 1395 compiled   92 ratio: 15.163
bytecodeBenchmark       2131 compiled  457 ratio:  4.663
sendBenchmark           1588 compiled  697 ratio:  2.278
doLoopsBenchmark        1088 compiled  657 ratio:  1.656
largeExplorers           326 compiled  359 ratio:  0.908
compilerBenchmark        727 compiled  699 ratio:  1.040
========================================================
Cumulative Time         4140 compiled 1370 ratio   3.022

The two most interesting benchmarks are largeExplorers and the
compilerBenchmark. largeExplorers opens a large explorer window, it's
an example of slow Morphic behavior.  They are the two real world
benchmarks, both purely use profiling to drive compilation, and both
are real applications. The other benchmarks are micro benchmarks.

The gains to compilerBenchmark are obtained by spending only 5% of the
time in compiled code and it's support routines. The gains should be
able to be improved by both better profiling and tuning. 

largeExplorers calls #@ frequently to construct points. This is a normal
Slang primitive for native code but the interpreter inlines it into a
special bytecode. Writing Exupery intermediate versions of #@ and #new
would allow Exupery to generate optimal code for object creation that
will be inlined by the primitive inlining system. 

The decision is whether to release as soon as all known testable
quality problems are fixed or to implement #new and #@ before
releasing. Releasing is quick on my side. The current development code
includes Andy's changes to allow Exupery VMs to be built on Windows.

Bryce
P.S.
Tony, the bug we were looking at on Saturday is now fixed. It was
caused by an accidental indirect recursion consuming all the C stack.
The change to newNativeMethod stopped exuperyBlock:Value: from
realizing that it was called from compiled code so it called compiled
code directly instead of setting newNativeMethod and returning.