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.
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
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@lists.squeakfoundation.org
-
Andrew Tween -
bryce＠kampjes.demon.co.uk