October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Run Spur run!!

by phil＠highoctane.be

Le 24 oct. 2014 15:51, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : > > The current x2 speed boost is due only to spur, not to sista. Sista will provide additional performance, but we have still things to do before production. > > The performance gain reported is due to (from most important to less important): > - the new GC has less overhead. 30% of the execution time used to be spent in the GC. > - the new object format speeds up some VM internal caches (especially inline caches for message sends due to an indirection for object classes with a class table). > - the new object format allows some C code to be converted into machine code routines, including block creation, context creation, primitive #at:put:, which is faster because switching from jitted code to C then back to jitted code generate a little overhead. > - characters are now immediate objects, which speeds up String accessing. > - the new object format has a larger hash which speeds up big hashed collections such as big sets and dictionaries. > - become is faster. Amazing comes to mind... Looks like a case of 1+1=much more than 2. Keep up the good work, you guys are setting a high standard for us to match. It is truly inspiring ! Phil > > > 2014-10-24 15:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >> >> thanks max, i completely forgotten about esug videos, looks like i found what to watch during the weekend :D >> >> On Fri, Oct 24, 2014 at 4:12 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> >>>> On 24.10.2014, at 15:06, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>> very nice >>>> >>>> so any more information to this, how exactly this optimization works and which kind of data will benefit from this ? >>> >>> >>> ClÃ©mentâs byte code set talk at ESUG: http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL… >>> ClÃ©mentâs Sista talk at ESUG (2 parts): >>> http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… >>> http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… >>> >>> Eliotâs Spur talk at ESUG (3 parts): >>> http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL… >>> http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL… >>> http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… >>> >>>> >>>> On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: >>>>> >>>>> remarkable!!! >>>>> >>>>> congratulations for the impressive results >>>>> >>>>> thanks for sharing! >>>>> >>>>> sebastian >>>>> >>>>> o/ >>>>> >>>>> > On 23/10/2014, at 17:40, Max Leske <maxleske(a)gmail.com> wrote: >>>>> > >>>>> > For those of you who missed this on IRC: >>>>> > >>>>> > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me? >>>>> > [3:32pm] henriksp: int := ZnUTF8Encoder new. >>>>> > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105 107 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench. >>>>> > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs Cog, if it's 8x vs Spur, that's just really impressive >>>>> > [3:44pm] Craig left the chat room. (Quit: Leaving.) >>>>> > [3:53pm] Craig joined the chat room. >>>>> > [4:08pm] VitamineD joined the chat room. >>>>> > [4:20pm] estebanlm: checking >>>>> > [4:21pm] estebanlm: Cog: 167,000 per second. >>>>> > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second. >>>>> > [4:23pm] estebanlm: henriksp: ping >>>>> > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds) >>>>> > [4:33pm] tinchodias joined the chat room. >>>>> > [4:34pm] henriksp: 70% more work done, nice! >>>>> > [5:09pm] >>>>> > >>>>> > >>>>> > Yay! :) >>>>> >>>> >>> >> >

Oct. 24, 2014

Re: [Pharo-dev] Run Spur run!!

by ClÃ©ment Bera

The current x2 speed boost is due only to spur, not to sista. Sista will provide additional performance, but we have still things to do before production. The performance gain reported is due to (from most important to less important): - the new GC has less overhead. 30% of the execution time used to be spent in the GC. - the new object format speeds up some VM internal caches (especially inline caches for message sends due to an indirection for object classes with a class table). - the new object format allows some C code to be converted into machine code routines, including block creation, context creation, primitive #at:put:, which is faster because switching from jitted code to C then back to jitted code generate a little overhead. - characters are now immediate objects, which speeds up String accessing. - the new object format has a larger hash which speeds up big hashed collections such as big sets and dictionaries. - become is faster. 2014-10-24 15:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > thanks max, i completely forgotten about esug videos, looks like i found > what to watch during the weekend :D > > On Fri, Oct 24, 2014 at 4:12 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 24.10.2014, at 15:06, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> very nice >> >> so any more information to this, how exactly this optimization works and >> which kind of data will benefit from this ? >> >> >> ClÃ©mentâs byte code set talk at ESUG: >> http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL… >> ClÃ©mentâs Sista talk at ESUG (2 parts): >> >> http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… >> >> http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… >> >> Eliotâs Spur talk at ESUG (3 parts): >> >> http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL… >> >> http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL… >> >> http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… >> >> >> On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre < >> sebastian(a)flowingconcept.com> wrote: >> >>> remarkable!!! >>> >>> congratulations for the impressive results >>> >>> thanks for sharing! >>> >>> sebastian >>> >>> o/ >>> >>> > On 23/10/2014, at 17:40, Max Leske <maxleske(a)gmail.com> wrote: >>> > >>> > For those of you who missed this on IRC: >>> > >>> > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me? >>> > [3:32pm] henriksp: int := ZnUTF8Encoder new. >>> > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105 107 >>> 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench. >>> > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs >>> Cog, if it's 8x vs Spur, that's just really impressive >>> > [3:44pm] Craig left the chat room. (Quit: Leaving.) >>> > [3:53pm] Craig joined the chat room. >>> > [4:08pm] VitamineD joined the chat room. >>> > [4:20pm] estebanlm: checking >>> > [4:21pm] estebanlm: Cog: 167,000 per second. >>> > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second. >>> > [4:23pm] estebanlm: henriksp: ping >>> > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds) >>> > [4:33pm] tinchodias joined the chat room. >>> > [4:34pm] henriksp: 70% more work done, nice! >>> > [5:09pm] >>> > >>> > >>> > Yay! :) >>> >>> >> >> >

Oct. 24, 2014

Re: [Pharo-dev] Run Spur run!!

by Eliot Miranda

On Oct 24, 2014, at 6:12 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 24.10.2014, at 15:06, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> very nice >> >> so any more information to this, how exactly this optimization works and which kind of data will benefit from this ? Just to be clear, the speed up measured here is due to Spur. Sista is in development and should produce even larger speed ups than the ~ -40% speed ups Spur achieves. Spur should speed up all pure Smalltalk code by - providing faster instantiation (including closures) - providing faster at:put: -providing faster GC (scavenging vs stackless scan-mark-compact) - providing much faster become - providing much faster wide string access via immediate characters > ClÃ©mentâs byte code set talk at ESUG: http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL… > ClÃ©mentâs Sista talk at ESUG (2 parts): > http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > Eliotâs Spur talk at ESUG (3 parts): > http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL… > http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL… > http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > >> >> On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>> remarkable!!! >>> >>> congratulations for the impressive results >>> >>> thanks for sharing! >>> >>> sebastian >>> >>> o/ >>> >>> > On 23/10/2014, at 17:40, Max Leske <maxleske(a)gmail.com> wrote: >>> > >>> > For those of you who missed this on IRC: >>> > >>> > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me? >>> > [3:32pm] henriksp: int := ZnUTF8Encoder new. >>> > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105 107 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench. >>> > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs Cog, if it's 8x vs Spur, that's just really impressive >>> > [3:44pm] Craig left the chat room. (Quit: Leaving.) >>> > [3:53pm] Craig joined the chat room. >>> > [4:08pm] VitamineD joined the chat room. >>> > [4:20pm] estebanlm: checking >>> > [4:21pm] estebanlm: Cog: 167,000 per second. >>> > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second. >>> > [4:23pm] estebanlm: henriksp: ping >>> > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds) >>> > [4:33pm] tinchodias joined the chat room. >>> > [4:34pm] henriksp: 70% more work done, nice! >>> > [5:09pm] >>> > >>> > >>> > Yay! :) Eliot (phone)

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Henrik Johansen

> On 24 Oct 2014, at 3:25 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 24 Oct 2014, at 3:20 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 24 Oct 2014, at 15:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> Isn't that for what NativeBoost prepareForProduction is used? >>>> >>>> >>> Yes! Now I remember, we solved that usecase already. >>> >>> Good. >> >> Nice! >> >> Maybe it should run after each build, or is that platform dependent ? >> > > > Nonononono. > The NB trailer only knows how to reinstall source from an original trailer with source pointer, so after first invocation, it will lose the source and start failing at next image startup. > > Cheers, > Henry Disregard that, prepareForProduction is implemented differently from what I described, and the argument mapping no longer works they way I seemed to remembered, using the cache if present. It should be safe to called when building, and allows dropping the changes file later on with no bad side-effects like my little hack. Cheers, Henry

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Henrik Johansen

> On 24 Oct 2014, at 3:20 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 24 Oct 2014, at 15:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Isn't that for what NativeBoost prepareForProduction is used? >>> >>> >> Yes! Now I remember, we solved that usecase already. >> >> Good. > > Nice! > > Maybe it should run after each build, or is that platform dependent ? > Nonononono. The NB trailer only knows how to reinstall source from an original trailer with source pointer, so after first invocation, it will lose the source and start failing at next image startup. Cheers, Henry

Oct. 24, 2014

Re: [Pharo-dev] RemotesManager Fishiness

by stepharo

I completely agree with you and one of the problems is that some people did not take well reviews of their code. I hope that we will be able to change this spirit. > [rant] > This is a weird class! It's protocol seems convoluted to me (even though it > only contains one operation!). > > The standard dialog #actionBlock: is eschewed for #selectedChangedBlock:, > which lets you know every time an item is checked or unchecked. I'm not > clear on the use case for that verbose level of updating. I would think > you'd mostly be interested in the final state once the dialog was accepted. > > In addition, there is a #selectedRemotes instVar, but it never gets updated > and has no getter. > > Maybe I'm just not getting it, but it seems like something was quickly > hacked together as an experiment to serve an immediate purpose without much > design thought. While I love new features, this worries me because it sounds > very familiar and three forks may be one too many ;) Maybe we should have a > more formal code review procedure for shiny new features (non-bug > fix/enhancement)? > [/rant] > > 14303 RemotesManager: Make more generally useful > https://pharo.fogbugz.com/default.asp?14303 > Initial slice incoming... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/RemotesManager-Fishiness-tp4786315.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 24, 2014

Re: [Pharo-dev] Run Spur run!!

by kilon alios

thanks max, i completely forgotten about esug videos, looks like i found what to watch during the weekend :D On Fri, Oct 24, 2014 at 4:12 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 24.10.2014, at 15:06, kilon alios <kilon.alios(a)gmail.com> wrote: > > very nice > > so any more information to this, how exactly this optimization works and > which kind of data will benefit from this ? > > > ClÃ©mentâs byte code set talk at ESUG: > http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL… > ClÃ©mentâs Sista talk at ESUG (2 parts): > > http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > Eliotâs Spur talk at ESUG (3 parts): > > http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL… > > http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL… > > http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > > On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > >> remarkable!!! >> >> congratulations for the impressive results >> >> thanks for sharing! >> >> sebastian >> >> o/ >> >> > On 23/10/2014, at 17:40, Max Leske <maxleske(a)gmail.com> wrote: >> > >> > For those of you who missed this on IRC: >> > >> > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me? >> > [3:32pm] henriksp: int := ZnUTF8Encoder new. >> > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105 107 >> 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench. >> > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs >> Cog, if it's 8x vs Spur, that's just really impressive >> > [3:44pm] Craig left the chat room. (Quit: Leaving.) >> > [3:53pm] Craig joined the chat room. >> > [4:08pm] VitamineD joined the chat room. >> > [4:20pm] estebanlm: checking >> > [4:21pm] estebanlm: Cog: 167,000 per second. >> > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second. >> > [4:23pm] estebanlm: henriksp: ping >> > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds) >> > [4:33pm] tinchodias joined the chat room. >> > [4:34pm] henriksp: 70% more work done, nice! >> > [5:09pm] >> > >> > >> > Yay! :) >> >> > >

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Sven Van Caekenberghe

> On 24 Oct 2014, at 15:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Isn't that for what NativeBoost prepareForProduction is used? >> >> > Yes! Now I remember, we solved that usecase already. > > Good. Nice! Maybe it should run after each build, or is that platform dependent ?

Oct. 24, 2014

Re: [Pharo-dev] Run Spur run!!

by Max Leske

> On 24.10.2014, at 15:06, kilon alios <kilon.alios(a)gmail.com> wrote: > > very nice > > so any more information to this, how exactly this optimization works and which kind of data will benefit from this ? ClÃ©mentâs byte code set talk at ESUG: http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL… <http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL…> ClÃ©mentâs Sista talk at ESUG (2 parts): http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… Eliotâs Spur talk at ESUG (3 parts): http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL… http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL… <http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL…> http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: > remarkable!!! > > congratulations for the impressive results > > thanks for sharing! > > sebastian > > o/ > > > On 23/10/2014, at 17:40, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > > > For those of you who missed this on IRC: > > > > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me? > > [3:32pm] henriksp: int := ZnUTF8Encoder new. > > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105 107 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench. > > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs Cog, if it's 8x vs Spur, that's just really impressive > > [3:44pm] Craig left the chat room. (Quit: Leaving.) > > [3:53pm] Craig joined the chat room. > > [4:08pm] VitamineD joined the chat room. > > [4:20pm] estebanlm: checking > > [4:21pm] estebanlm: Cog: 167,000 per second. > > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second. > > [4:23pm] estebanlm: henriksp: ping > > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds) > > [4:33pm] tinchodias joined the chat room. > > [4:34pm] henriksp: 70% more work done, nice! > > [5:09pm] > > > > > > Yay! :) > >

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Marcus Denker

> On 24 Oct 2014, at 15:05, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-10-24 14:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >> On 24 Oct 2014, at 14:06, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> >>>> -- >>>> Dr. Geo - http://drgeo.eu <http://drgeo.eu/> >>>> iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> >>> >>> Few NB-FFI methods will work without sources, as many rely on the automatic argument name -> signature mapping. >>> This happens the first time a method is called after startup, and platform-specific recompilation occurs. When the argument names are decompiled as arg1, arg2, the mapping will fail. >>> (Other NB methods that generate machine code without using NB-FFI, will still work though) >>> >>> Theoretically, one could solve this by internalizing the source of all NB-FFI calling method in the method trailer* at the end of deployment preparation process. (so no NB methods have a chance to trigger before image save) >>> NB puts native code into the same trailer space, and combing different method trailer types is currently unsupported (AFAIK), but the transition >>> TrailerWithEmbeddedSource** -> TrailerWithNBCode should happen only once. >> >> Yes it would be good to have a method for doing that. >> https://pharo.fogbugz.com/default.asp?14311 <https://pharo.fogbugz.com/default.asp?14311> > > No, pleaseâ¦ we need to simplify, not make everything complex. > > It would be much better to spend engery on getting rid of .sources and changesâ¦ we are drowning in complexity with > the current stuff. > > Marcus > > > Isn't that for what NativeBoost prepareForProduction is used? > > Yes! Now I remember, we solved that usecase already. Good. Ceterum Censeo: We need to get rid of .sources and .changes. Marcus

Oct. 24, 2014