It will be great. Hilaire
2009/3/7 <[email protected]>: > 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 > -- http://blog.ofset.org/hilaire _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
