Is it worth releasing now?

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.

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

Hi Bryce,
The benchmark numbers are looking good. Congratulations, and keep up the good
work.

If you decide to release, then I can build a new Win32 VM, if necessary. Just
let me know the appropriate package versions.

Will you be creating an image with Exupery pre-installed, or only the packages
for people to install themselves?  I like to download images with everything
set-up, so that I know I have the right versions of everything, installed in the
correct order. But I understand why others may prefer to do their own install.

(Off-topic : How did the UK smalltalk meet go on Friday/Saturday? I couldn't
make it due to attending a wedding, but hopefully I'll be able to go to the next
one)

Cheers,
Andy



_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

Hi Andrew,

Andrew Tween writes:
 > Hi Bryce,
 > The benchmark numbers are looking good. Congratulations, and keep up the good
 > work.

Thanks.

 > If you decide to release, then I can build a new Win32 VM, if necessary. Just
 > let me know the appropriate package versions.

Thanks again. I plan to fix a few more bugs then release. Having both
pre-built Windows and Linux VMs would be great.

Theres some methods that fail to compile due to compiler bugs that
don't cause crashes.  I want to remove these errors before releasing.
One big advantage of the register allocator is it's liveness analysis
is very good at catching bugs at compile time.

It might also be sensible to move all the VM code into the Exupery
version of VMMaker, that way it's should be easier to track when a new
VM is needed. At the moment, the only way is to either use a released
version or to build one yourself. It's hard to know when the released
pre-built VMs are no longer useful for development versions.

 > Will you be creating an image with Exupery pre-installed, or only the packages
 > for people to install themselves?  I like to download images with everything
 > set-up, so that I know I have the right versions of everything, installed in the
 > correct order. But I understand why others may prefer to do their own install.

I could, I haven't really thought about packaged images. Exupery
itself shouldn't have any dependencies on other external packages.
The tests do have a few dependencies. An image set up for Exupery
development could be useful, that would just leave people to get the
right VM source, or a prebuilt VM. It could drop the barriers to
getting started.

 > (Off-topic : How did the UK smalltalk meet go on Friday/Saturday? I couldn't
 > make it due to attending a wedding, but hopefully I'll be able to go to the next
 > one)

Both days went well. I hope you enjoyed the wedding.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery