Hilaire Fernandes writes: > 2009/3/7 <[email protected]>: > > > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
