- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Spur performance report...

by Eliot Miranda

Hi David, On Tue, Apr 22, 2014 at 4:21 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Tue, Apr 22, 2014 at 03:44:46PM -0700, Eliot Miranda wrote: > > Hi Nicolas, > > > > On Tue, Apr 22, 2014 at 3:21 PM, Nicolas Cellier < > > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > > > 2014-04-23 0:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > >> > > >> Hi All, > > >> > > >> I should write a blog post on this, but I can't wait... > > >> > > >> In recent days I've written a script to build a Cog VMMaker image from > > >> Squeak 4.5. See > http://www.squeakvm.org/svn/squeak/branches/Cog/image. > > >> This has allowed me to run the current Cog VM against Spur > side-to-side. > > >> > > >> To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro > using > > >> the current Cog VM takes about 2 and a half minutes: > > >> > > >> McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st > > >> real 2m30.671s > > >> user 2m15.683s > > >> sys 0m5.283s > > >> > > >> To build the equivalent image using Spur takes about 1 and a half > minutes: > > >> McStalker.image$ time spurcfvm CogVMMaker-spur.image > > >> BuildSqueak45Image.st > > >> real 1m34.943s > > >> user 1m23.666s > > >> sys 0m6.810s > > >> > > >> Comparing: > > >> > > >> 94.943 - 150.671 / 150.671 * 100 -36.99 > > >> 83.666 - 135.681 / 135.681 * 100 -38.34 > > >> 150.671 / 94.943 1.59 > > >> 135.681 / 83.666 1.62 > > >> > > >> that's about a -37% speedup, or 1.6x faster. > > >> -- > > >> best, > > >> Eliot > > >> > > >> > > > So this is loading .mcz from package cache, uncompressing, compiling, > > > installing the packages. > > > > > > > Exactly. > > > > > > > I presume this qualifies as a macro benchmark... > > > > > > > yes :-) > > > > That's quite impressive. I suspect that if you run this under a time > profiler > that you'll see a lot of time going into I/O even though it is using a > local > MC cache. That would mean that this macro benchmark is quite conservative, > and the actual computational speedup may be considerably better than 1.6x. > I think that the i/o time is included in the "sys" sub-total, which will include reading the image files and the mczs. The rest is, as they say, up to us. So the difference in performance between including and excluding I/O is -36.99 vs -38.34, or 1.59 vs 1.62. > Bravo! > > Dave > -- best, Eliot

April 22, 2014

Re: [Pharo-dev] [Vm-dev] Spur performance report...

by David T. Lewis

On Tue, Apr 22, 2014 at 03:44:46PM -0700, Eliot Miranda wrote: > Hi Nicolas, > > On Tue, Apr 22, 2014 at 3:21 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > 2014-04-23 0:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > >> > >> Hi All, > >> > >> I should write a blog post on this, but I can't wait... > >> > >> In recent days I've written a script to build a Cog VMMaker image from > >> Squeak 4.5. See http://www.squeakvm.org/svn/squeak/branches/Cog/image. > >> This has allowed me to run the current Cog VM against Spur side-to-side. > >> > >> To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro using > >> the current Cog VM takes about 2 and a half minutes: > >> > >> McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st > >> real 2m30.671s > >> user 2m15.683s > >> sys 0m5.283s > >> > >> To build the equivalent image using Spur takes about 1 and a half minutes: > >> McStalker.image$ time spurcfvm CogVMMaker-spur.image > >> BuildSqueak45Image.st > >> real 1m34.943s > >> user 1m23.666s > >> sys 0m6.810s > >> > >> Comparing: > >> > >> 94.943 - 150.671 / 150.671 * 100 -36.99 > >> 83.666 - 135.681 / 135.681 * 100 -38.34 > >> 150.671 / 94.943 1.59 > >> 135.681 / 83.666 1.62 > >> > >> that's about a -37% speedup, or 1.6x faster. > >> -- > >> best, > >> Eliot > >> > >> > > So this is loading .mcz from package cache, uncompressing, compiling, > > installing the packages. > > > > Exactly. > > > > I presume this qualifies as a macro benchmark... > > > > yes :-) > That's quite impressive. I suspect that if you run this under a time profiler that you'll see a lot of time going into I/O even though it is using a local MC cache. That would mean that this macro benchmark is quite conservative, and the actual computational speedup may be considerably better than 1.6x. Bravo! Dave

April 22, 2014

Monticello Whitewash...

by Eliot Miranda

ugh... after opening a multi-window browser on the Spur classes in the automatically-created VMMaker image I notice once again that Monticello doesn't preserve class organization order on load. grr.... Anyone up to fixing this? -- best, Eliot

April 22, 2014

Re: [Pharo-dev] [Vm-dev] Spur performance report...

by Eliot Miranda

Hi Nicolas, On Tue, Apr 22, 2014 at 3:21 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2014-04-23 0:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Hi All, >> >> I should write a blog post on this, but I can't wait... >> >> In recent days I've written a script to build a Cog VMMaker image from >> Squeak 4.5. See http://www.squeakvm.org/svn/squeak/branches/Cog/image. >> This has allowed me to run the current Cog VM against Spur side-to-side. >> >> To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro using >> the current Cog VM takes about 2 and a half minutes: >> >> McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st >> real 2m30.671s >> user 2m15.683s >> sys 0m5.283s >> >> To build the equivalent image using Spur takes about 1 and a half minutes: >> McStalker.image$ time spurcfvm CogVMMaker-spur.image >> BuildSqueak45Image.st >> real 1m34.943s >> user 1m23.666s >> sys 0m6.810s >> >> Comparing: >> >> 94.943 - 150.671 / 150.671 * 100 -36.99 >> 83.666 - 135.681 / 135.681 * 100 -38.34 >> 150.671 / 94.943 1.59 >> 135.681 / 83.666 1.62 >> >> that's about a -37% speedup, or 1.6x faster. >> -- >> best, >> Eliot >> >> > So this is loading .mcz from package cache, uncompressing, compiling, > installing the packages. > Exactly. > I presume this qualifies as a macro benchmark... > yes :-) > I didn't follow the full flow of changes, how difficult is it right now to > bootstrap a spur.image? > Right now the transformation of the images is straight-forward, e.g.: SpurBootstrap bootstrapImage: 'Squeak-4.5-All-in-One.app/Contents/Resources/Squeak4.5-13680' But fixing the Monticello packages is a little more involved. One has to collect the relevant packages in a directory (Kernel, Collections & System) and then do e.g. (SpurBootstrapMonticelloPackagePatcher new from: 'image/package-cache' to: 'image/spur-package-cache') patch and then load the packages into the Spur image. When I get my ass in gear this step should be unnecessary since http://source.squeak.org/spur is ready and waiting. So the Spur trunk for Squeak V5.0 will parallel Squeak 4.6 and hopefully supplant it soon enough. The main hold up right now is the combination of the facts that the current compaction algorithm doesn't work well, and image start-up always adds 50% of image size as free space, so the image balloons on each save. I'm finally getting back to working on the compaction algorithm after a very satisfying three weeks working with ClÃ©ment BÃ©ra on Sista. So I hope to have movement on releasing Spur for the 4.6/5.0 development cycle soon. -- best, Eliot

April 22, 2014

Spur performance report...

by Eliot Miranda

Hi All, I should write a blog post on this, but I can't wait... In recent days I've written a script to build a Cog VMMaker image from Squeak 4.5. See http://www.squeakvm.org/svn/squeak/branches/Cog/image. This has allowed me to run the current Cog VM against Spur side-to-side. To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro using the current Cog VM takes about 2 and a half minutes: McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st real 2m30.671s user 2m15.683s sys 0m5.283s To build the equivalent image using Spur takes about 1 and a half minutes: McStalker.image$ time spurcfvm CogVMMaker-spur.image BuildSqueak45Image.st real 1m34.943s user 1m23.666s sys 0m6.810s Comparing: 94.943 - 150.671 / 150.671 * 100 -36.99 83.666 - 135.681 / 135.681 * 100 -38.34 150.671 / 94.943 1.59 135.681 / 83.666 1.62 that's about a -37% speedup, or 1.6x faster. -- best, Eliot

April 22, 2014

Re: [Pharo-dev] Pharo success story for Issys Tracking broken?

by Torsten Bergmann

Yes - but the question remains where did this story come from. I would like to know more about it. Thx T. > Gesendet: Dienstag, 22. April 2014 um 16:20 Uhr > Von: "Marcus Denker" <marcus.denker(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Pharo success story for Issys Tracking broken? > > > On 22 Apr 2014, at 13:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Torsten Bergmann wrote > >> Unfortunately none of the links work. Any infos on that? > > > > I did a little googling and checked the wayback machine; didn't come up with > > anything relevantâ¦ > > > > I have removed the article for nowâ¦ > > Marcus > > >

April 22, 2014

Re: [Pharo-dev] updated documentation on magritte?

by phil＠highoctane.be

On Tue, Apr 22, 2014 at 9:14 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On 22 Apr 2014, at 20:20, stepharo <stepharo(a)free.fr> wrote: > > > Not that I know. > > I started a chapter on the pharo for the entreprise (with the idea to > base it on the seaside book) but I need help. > > If you start writing a draft I will do a pass. > > I was fearing thatâ¦ but ok :) > I have collected quite a number of items regarding magritte. And I used 3.x for one project of mine, which exposed a number of elements. I'll try to make a package with all of it. Phil > > > > > Stef > > > > On 22/4/14 09:28, Esteban Lorenzano wrote: > >> Hi, > >> > >> is there an updated documentation on magritte? where can I find it? > >> > >> cheers, > >> Esteban > >> > >> > > > > > > >

April 22, 2014

Re: [Pharo-dev] About fonts (again)

by Nicolas Cellier

2014-04-22 21:30 GMT+02:00 stepharo <stepharo(a)free.fr>: > > On 22/4/14 14:19, Tudor Girba wrote: > > I do not see what this has to do with anything. > > Right now we are offering the possibility to not be able to load > FreeType fonts and this leads to buggy behavior when the user starts > playing with that toggle. > > > In fact this is buggy even without that. The system reports strike and > freetype fonts when we are in ft mode :( > > > Are you questionning about updateFontsAtImageStartup? The reason for not wanting to update fonts at image startup was to avoid loosing time at startup. http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009358.html If this was a valuable setting at that time, what makes it not valuable now? Or are you questionning about presence of FreeType fonts in FontChooser? I have FT on but updateFTAtStartup off, and for seeing the FT fonts I have to open the dialog, press update button, close the dialog, reopen, and only then I can see the FreeType fonts. Is that the bug you're after? > I fail to see why we need the option in the first place. All I am > saying is that we should remove the option from the settings browser and > simply have the freetype fonts enable all the time. This means that you > will still be able to load the bitmap fonts without problems just like > before. > > And it is our (as builders of Pharo) responsibilities to design. The > user can say if he likes it or not and in our case can even try to > contribute. But, this does not take the design responsibility from our > shoulders. > > Doru > > > On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > >> 2014-04-22 8:21 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> I am not arguing for dropping of bitmap fonts at all. I am only arguing >>> for removing the option of not having freetype. People on slow devices will >>> still be able to use the bitmap fonts. >>> >>> Is that wrong? >>> >> >> Well, look at it this way: who should be able to have the final word on >> what side of the speed/prettiness dichotomy Pharo should be: the user or >> the system? >> >> Cheers, >> Sergi >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

April 22, 2014

Re: [Pharo-dev] About fonts (again)

by Tudor Girba

Why is this buggy? Right now, the meaning of the checkbox is to allow the user to have FT in addition to bitmap fonts. That is why I say we should just drop the checkbox altogether and we have solved a source of problems. We can rethink the infrastructure for Pharo 4. Doru On Tue, Apr 22, 2014 at 9:30 PM, stepharo <stepharo(a)free.fr> wrote: > > On 22/4/14 14:19, Tudor Girba wrote: > > I do not see what this has to do with anything. > > Right now we are offering the possibility to not be able to load > FreeType fonts and this leads to buggy behavior when the user starts > playing with that toggle. > > > In fact this is buggy even without that. The system reports strike and > freetype fonts when we are in ft mode :( > > > I fail to see why we need the option in the first place. All I am saying > is that we should remove the option from the settings browser and simply > have the freetype fonts enable all the time. This means that you will still > be able to load the bitmap fonts without problems just like before. > > And it is our (as builders of Pharo) responsibilities to design. The > user can say if he likes it or not and in our case can even try to > contribute. But, this does not take the design responsibility from our > shoulders. > > Doru > > > On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > >> 2014-04-22 8:21 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> I am not arguing for dropping of bitmap fonts at all. I am only arguing >>> for removing the option of not having freetype. People on slow devices will >>> still be able to use the bitmap fonts. >>> >>> Is that wrong? >>> >> >> Well, look at it this way: who should be able to have the final word on >> what side of the speed/prettiness dichotomy Pharo should be: the user or >> the system? >> >> Cheers, >> Sergi >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

April 22, 2014

Re: [Pharo-dev] About fonts (again)

by stepharo

On 22/4/14 14:19, Tudor Girba wrote: > I do not see what this has to do with anything. > > Right now we are offering the possibility to not be able to load > FreeType fonts and this leads to buggy behavior when the user starts > playing with that toggle. In fact this is buggy even without that. The system reports strike and freetype fonts when we are in ft mode :( > I fail to see why we need the option in the first place. All I am > saying is that we should remove the option from the settings browser > and simply have the freetype fonts enable all the time. This means > that you will still be able to load the bitmap fonts without problems > just like before. > > And it is our (as builders of Pharo) responsibilities to design. The > user can say if he likes it or not and in our case can even try to > contribute. But, this does not take the design responsibility from our > shoulders. > > Doru > > > On Tue, Apr 22, 2014 at 1:48 PM, Sergi Reyner <sergi.reyner(a)gmail.com > <mailto:sergi.reyner@gmail.com>> wrote: > > 2014-04-22 8:21 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > I am not arguing for dropping of bitmap fonts at all. I am > only arguing for removing the option of not having freetype. > People on slow devices will still be able to use the bitmap fonts. > > Is that wrong? > > > Well, look at it this way: who should be able to have the final > word on what side of the speed/prettiness dichotomy Pharo should > be: the user or the system? > > Cheers, > Sergi > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

April 22, 2014