Last updated at 7:55 pm UTC on 8 April 2009
Installing Exupery is fairly simple. Exupery does need a custom VM to run, the compiler can be installed without it but it's impossible to run compiled code. You can always switch back to a stock VM after installing Exupery, only Exupery will stop working.
- Download an Exupery VM from
- Install Exupery from either SqueakMap or SqueakSource. If you don't install VMMaker first it will complain about a lot of classes in Interpreter and ExuperyPlugin, you can ignore these because they are for building the VM.
- In SqueakSource there are two Exupery's: Exupery and Exupery39 which one to install?
- Exupery. Exupery39 was just for porting to 3.9 images, all it's changes are now in the main VMs.
- While running the Exupery VM run all the tests in the class ExuperyStoryTests. These are SUnit tests that test the functionality end to end by compiling methods then testing the compiled code. They should all pass. Congratulations, you've successfully installed Exupery.
- Previous VMs are here http://ftp.squeak.org/Exupery/vms/.
NOTE: Exupery 0.09 needs VMMaker loaded to run. This is because it's calling an extension method on Array provided by VMMaker.
A prebuilt image
Exupery compiles to a native code cache. This cache can be flushed by re-initialising it
with "Exupery initialiseExupery" which recover from bugs in compiled code. Methods have to
be explicitly compiled.
- Run the benchmarks to see if it made a difference "ExuperyBenchmarks new run"
- Look in the transcript to see the result. This will have benchmarked a few methods against the interpreter.
Then to compile specific methods by hand.
- First initialise Exupery using "Exupery initialiseExupery"
- Compile a method "Exupery compileMethod: #benchmark class: Integer". You should compile both Array>>at: and Array>>at:put: to get a performance improvement.
- Check that it's compiled "0 tinyBenchmarks". Running the benchmark before compiling is nice,
- Initialising Exupery again with "Exupery initialiseExupery" will flush the code cache forcing the system to stop using compiled code.
Using the background compiler
First initialise the code cache with:
Start the background compiler with:
To stop the background compiler use:
The background compiler and the code cache will be stopped and flushed on every image save. This is overkill but an easy way to ensure that there's never any Exupery contexts or code registered on an image save. The native code will not be there when the image is restarted which could cause a crash.
Using the compiling profiler
The 0.07 release introduces a compiling profiler. This profiler will compile the top 10 most frequently used methods in the block. It's the beginning of an automated driver. The aim is to balance ease of use with some predictability. A full JIT is a little too uncontrolled while doing the initial alpha testing.
ExuperyProfiler profileAndCompile: [Array allInstances explore]
Will compile the top ten methods used when opening a large explorer. Unfortunately often not enough is compiled to speed up real programs, I'm working on that.
At the moment Exupery is just a compiler, you need to tell it what you want it to compile. This is deliberate, while it's still under active development it's easier to debug if I know what I compiled. There is a profiler that can be used to drive the compiler (ExuperyProfiler).
Ways to help
The current goal is to make Exupery useful. To do this I need to understand where a significant speed improvement would be useful, useful enough use a beta compiler. The easiest way to help is to play with Exupery (currently only possible on Linux/x86 32 bit) and help work out what's minimally
needed to be useful.