March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by Hilaire Fernandes

Next I tried the Exupery profiler, but still the benchmark is not as good as without the compiler. Hilaire 2009/3/7 Hilaire Fernandes <hilaire(a)ofset.org>: > And the fourth benchmark with compiled methods > > > > 2009/3/7 Hilaire Fernandes <hilaire(a)ofset.org>: >> 2009/3/7 Â <bryce(a)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 ? >> >> Hilaire >> > > > > -- > http://blog.ofset.org/hilaire > -- http://blog.ofset.org/hilaire

March 7, 2009

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by Hilaire Fernandes

And the fourth benchmark with compiled methods 2009/3/7 Hilaire Fernandes <hilaire(a)ofset.org>: > 2009/3/7 Â <bryce(a)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 ? > > Hilaire > -- http://blog.ofset.org/hilaire

March 7, 2009

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by Hilaire Fernandes

2009/3/7 <bryce(a)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 ? Hilaire

March 7, 2009

Re: [Pharo-project] {Spam?} Re: Pharo + Exupery VM + Something else than Accuny

by Schwab,Wilhelm K

Bryce, I'll play dumb here - actually, I'm not playing in this case :) The little I know about Exupery comes from FAQs. In the past at least, you cautioned against enabling dynamic compiling of methods, at least in production. How does that square with full-inlining? Are they different concepts, or have thing improved enough that you are now confident enough to throw the switch? Full-inlining sounds like it could consume a lot of space. Is that a concern, or does the selection of what it compiles keep it manageable? How does it decide what to compile, and (more relevant to my dumb questions) how does that differ from the dynamic compilation? Please don't feel attacked - I'm simply trying to understand what is hopefully just around the corner. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of bryce(a)kampjes.demon.co.uk Sent: Saturday, March 07, 2009 6:55 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: {Spam?} Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny Hilaire Fernandes writes: > I am talking about performance, benchmark, etc. > Is it not Exupery about improving the speed of the VM? Exupery is, these VMs include the support Exupery needs but the compiler is in the image. If you load and start Exupery you may see some gains. I haven't yet tuned the background compiler for practical use, it currently will compile every method it sees which is great for debugging but not good for providing a practical speed improvement. Compiled code takes up more cache than bytecode so there can be a loss due to compiling methods that are hardly ever used. Here's the current benchmarks: arithmaticLoopBenchmark 390 compiled 80 ratio: 4.875 bytecodeBenchmark 724 compiled 250 ratio: 2.895 sendBenchmark 663 compiled 385 ratio: 1.722 doLoopsBenchmark 381 compiled 235 ratio: 1.621 pointCreation 394 compiled 389 ratio: 1.013 largeExplorers 269 compiled 210 ratio: 1.280 compilerBenchmark 273 compiled 250 ratio: 1.092 Cumulative Time 413.408 compiled 232.706 ratio 1.777 With these VMs you could load Exupery from either SqueakMap or Universes and start it. Documentation is here: http://wiki.squeak.org/squeak/Exupery I may add full method inlining next rather than tune for practical performance. Full method inlining will speed up common sends extensively. In summary, there may be a practical performance gain now or there may not but Exupery is getting close to being seriously useful. Bryce _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 7, 2009

Re: [Pharo-project] Connector replacement packages for Pharo

by Alexandre Bergel

This is trivial to achieve. I will give a try this week end. Alexandre On 6 Mar 2009, at 22:07, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > Alexandre Bergel writes: >> Hi Bryce, >> >> I suggest you to use Mondrian. >> http://www.squeaksource.com/Mondrian.html >> >> Arrowed edges does not properly work for now. But it is on my todo >> list. If you have an example of a diagram you're interested in... > > Here's an example. It's basic boxes with arrows and some colour > to indicate what the boxes are. > > It's a control flow graph of intermediate code. I use it to > make inspecting Exupery's intermediate more understandable. > > Bryce > > <exuperyGraph.jpg>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 7, 2009

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by bryce＠kampjes.demon.co.uk

Hilaire Fernandes writes: > I am talking about performance, benchmark, etc. > Is it not Exupery about improving the speed of the VM? Exupery is, these VMs include the support Exupery needs but the compiler is in the image. If you load and start Exupery you may see some gains. I haven't yet tuned the background compiler for practical use, it currently will compile every method it sees which is great for debugging but not good for providing a practical speed improvement. Compiled code takes up more cache than bytecode so there can be a loss due to compiling methods that are hardly ever used. Here's the current benchmarks: arithmaticLoopBenchmark 390 compiled 80 ratio: 4.875 bytecodeBenchmark 724 compiled 250 ratio: 2.895 sendBenchmark 663 compiled 385 ratio: 1.722 doLoopsBenchmark 381 compiled 235 ratio: 1.621 pointCreation 394 compiled 389 ratio: 1.013 largeExplorers 269 compiled 210 ratio: 1.280 compilerBenchmark 273 compiled 250 ratio: 1.092 Cumulative Time 413.408 compiled 232.706 ratio 1.777 With these VMs you could load Exupery from either SqueakMap or Universes and start it. Documentation is here: http://wiki.squeak.org/squeak/Exupery I may add full method inlining next rather than tune for practical performance. Full method inlining will speed up common sends extensively. In summary, there may be a practical performance gain now or there may not but Exupery is getting close to being seriously useful. Bryce

March 7, 2009

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by Hilaire Fernandes

I am talking about performance, benchmark, etc. Is it not Exupery about improving the speed of the VM? 2009/3/7 Damien Cassou <damien.cassou(a)gmail.com>: > On Sat, Mar 7, 2009 at 11:57 AM, Hilaire Fernandes <hilaire(a)ofset.org> wrote: >> And what about the speed improvment ? > > Should there be any? I haven't played enough with it. If you are > talking about the closures, I don't think I will see any improvement > until the blocks are converted and I haven't done that. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire

March 7, 2009

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by Damien Cassou

On Sat, Mar 7, 2009 at 11:57 AM, Hilaire Fernandes <hilaire(a)ofset.org> wrote: > And what about the speed improvment ? Should there be any? I haven't played enough with it. If you are talking about the closures, I don't think I will see any improvement until the blocks are converted and I haven't done that. -- Damien Cassou http://damiencassou.seasidehosting.st

March 7, 2009

Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

by Hilaire Fernandes

And what about the speed improvment ? 2009/3/7 Damien Cassou <damien.cassou(a)gmail.com>: > Hi, > > I'm playing with the Exupery VM on Pharo. If I change the font to

March 7, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by Bruce O'Neel

Hi, Since this seems to work well for the x86 folks, Bryce, would you mind uploading a source tarball so that others could build for other unixy system? That would be great! If you could do this then I'll put my feeble attempts to build VMs on hold since it's probably better for only one person to do this work per platform, rather than have a confusing set of built VMs. :-) cheers bruce On Wed, Mar 04, 2009 at 08:39:11PM +0000, bryce(a)kampjes.demon.co.uk wrote: > StÃ©phane Ducasse writes: > > creating a unix vm. > > Here's a Unix VM built with an up to date VMMaker and a Windows VM: > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-win32.zip > > Both have the closure bytecodes and the FreeType bitblit extensions. > The Linux VM includes the FreeType plugin, the Windows VM doesn't. > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 7, 2009