Hilaire Fernandes writes:
2009/3/7 <bryce@kampjes.demon.co.uk>:
With these VMs you could load Exupery from either SqueakMap or Universes and start it. Documentation is here:
I installed exupery code in pharo 203, run the test, got 4 errors on #testBlockBug3, #testBlockNonLocalReturnRecycledContext, #testDelayWaitStreeTest, #testStressFailure1
Next I did three benchmarks on 3 different setups with DrGeo MessageTally spyOn [Carre new].
Carre new instanciate a DrGeo canvas with Smalltalk programmed figure, it results in a self-repeating sketch (see screenshot)
1. image with exupery runned with exupery VM 2. image without exupery runned with stock 3.9 VM 3. image without exupery runned with exupery VM
I used exupery image Damien pointed to in his email.
Do you want the images ?
Thanks, I'd like to look at the images later but probably not until after the next release. The decision to work on full method inlining is a decision to not do much tuning until after a critical optimisation is in place. It is possible that running Exupery can slow down code. Normally this is because it either didn't compile something it needed to for a given benchmark. In your case it's suspicious that it's only compiled one of the leaf methods. It's also possible that I need to optimise something where Exupery is slower than the interpreter, I'm not aware of any such cases but further profiling may find some. Bryce