It will be great. Hilaire 2009/3/7 <bryce@kampjes.demon.co.uk>:
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project