Tuning Opal Optimizations
Locked
12
12
Tuning Opal Optimizations
 
|
Hi,
It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. Is there a way to tune this ? Can it be set at a level higher than in each method ? Sven |
Re: Tuning Opal Optimizations
|
|
On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <[hidden email]> wrote: > Hi, > > It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? > RBMessageNode has #isInlined that returns true… not all cases where the selector is send it is optimised, so a list would be one of “possiblyoptimized” selectors… maybe #isInlined could check first against that list to quickly return false for all the other selectors. > In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. > oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly re-compiling and executing the ifTrue:, but it’s a bit of work to get it right for all cases… so we did not finish that. But it would be possible... > Is there a way to tune this ? > Can it be set at a level higher than in each method ? > Yes, you can do it per class-hierarchy… you can implement on the class side a method to parametrize the compiler: compiler ^super compiler options: #(- optionInlineTimesRepeat) Marcus |
Re: Tuning Opal Optimizations
|
|
On 19 Nov 2013, at 16:20, Marcus Denker <[hidden email]> wrote: > > On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <[hidden email]> wrote: > >> Hi, >> >> It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? >> > RBMessageNode has #isInlined that returns true… not all cases where the selector is send it is optimised, so a list would be one of “possiblyoptimized” selectors… > maybe #isInlined could check first against that list to quickly return false for all the other selectors. > >> In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. >> > oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly re-compiling and executing the ifTrue:, but it’s a bit of work to get it right for all cases… so we did not finish > that. But it would be possible... > >> Is there a way to tune this ? >> Can it be set at a level higher than in each method ? >> > > Yes, you can do it per class-hierarchy… you can implement on the class side a method to parametrize the compiler: > > compiler > ^super compiler options: #(- optionInlineTimesRepeat) Thanks, Marcus, that works just great. Sven > Marcus > > > |
|
|
In reply to this post by Marcus Denker-4
On 19 November 2013 16:20, Marcus Denker <[hidden email]> wrote:
.. and i feel really glad that Marcus armed my idea of option specification e.g. #(+ optionToEnable1 - optionToDisable anotherOptionToDisable + optionToEnable2 ) :)
-- Best regards, Igor Stasenko. |
Re: Tuning Opal Optimizations
|
|
The only thing that annoyed me is that I failed to discover the incantation thru sender/implementor chain because some messages are constructed... Of course, once you've learned the incantation, it's OK...I tried the senders of timesRepeat: then the senders of corresponding visitor message (no image near my keyboard to check the name). 2013/11/20 Igor Stasenko <[hidden email]>
|
Re: Tuning Opal Optimizations
|
|
On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier <[hidden email]> wrote:
that's an anti-pattern to be avoided. One can use dictionaries to make the link explicit, then one has a chance of tracking things down. Always use something equivalent to
self perform: (Dictionary newFromPairs: #(#timesRepeat: #optimizeTimesRepeat: ...) at: message) with: ... instead of self perform: ('compile', message) asSymbol with:
It'll be far clearer, and (cuz the dictionary will be precomputed) it'll be faster too.
best, Eliot
|
Re: Tuning Opal Optimizations
|
|
Nice one, Eliot! :-) -- Cheers, Peter.
|
|
|
In reply to this post by Eliot Miranda-2
2013/11/20 Eliot Miranda <[hidden email]>
Nice idea. I've never liked this dynamic dispatch with string/symbol manipulation in Opal.
I added your fix in Opal on my computer right now, I put the optimized dictionary in a class variable. I will check with Marcus tomorrow if he's fine with it we will add it in Pharo 3.0 in the next few days.
However I didn't see compilation time being faster, I guess the performance improvement is not noticeable in the whole image recompilation time.
|
Re: Tuning Opal Optimizations
|
|
On Wed, Nov 20, 2013 at 10:54 AM, Clément Bera <[hidden email]> wrote:
Right. It's a mcro-optimization: | d | d := Dictionary newFromPairs: #('your' yourself). { [1000000 timesRepeat: [self perform: ('your', 'self') asSymbol]] timeToRun.
[1000000 timesRepeat: [self perform: (d at: 'your')]] timeToRun } #(796 341) :-) on my 2.2GHz Core i7 MBP, Cog r2798 VMMaker.oscog-eem.496
best, Eliot
|
Re: Tuning Opal Optimizations
|
|
In reply to this post by Eliot Miranda-2
On 20 Nov 2013, at 18:53, Eliot Miranda <[hidden email]> wrote: > > > > On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier <[hidden email]> wrote: > The only thing that annoyed me is that I failed to discover the incantation thru sender/implementor chain because some messages are constructed... > > that's an anti-pattern to be avoided. One can use dictionaries to make the link explicit, then one has a chance of tracking things down. Always use something equivalent to > > self perform: (Dictionary newFromPairs: #(#timesRepeat: #optimizeTimesRepeat: ...) at: message) with: ... > > instead of > > self perform: ('compile', message) asSymbol with: > > It'll be far clearer, and (cuz the dictionary will be precomputed) it'll be faster too. I don’t get the ‘because the Dictionary will be precomputed’ in the code example you give. On the contrary, you will create a new Dictionary every time you execute your example, no ? > I tried the senders of timesRepeat: then the senders of corresponding visitor message (no image near my keyboard to check the name). > Of course, once you've learned the incantation, it's OK... > > > 2013/11/20 Igor Stasenko <[hidden email]> > > > > On 19 November 2013 16:20, Marcus Denker <[hidden email]> wrote: > > On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <[hidden email]> wrote: > > > Hi, > > > > It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? > > > RBMessageNode has #isInlined that returns true… not all cases where the selector is send it is optimised, so a list would be one of “possiblyoptimized” selectors… > maybe #isInlined could check first against that list to quickly return false for all the other selectors. > > > In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. > > > oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly re-compiling and executing the ifTrue:, but it’s a bit of work to get it right for all cases… so we did not finish > that. But it would be possible... > > > Is there a way to tune this ? > > Can it be set at a level higher than in each method ? > > > > Yes, you can do it per class-hierarchy… you can implement on the class side a method to parametrize the compiler: > > compiler > ^super compiler options: #(- optionInlineTimesRepeat) > > > .. and i feel really glad that Marcus armed my idea of option specification e.g. > > #(+ optionToEnable1 - optionToDisable anotherOptionToDisable + optionToEnable2 ) > > :) > > > Marcus > > > > > > > -- > Best regards, > Igor Stasenko. > > > > > -- > best, > Eliot |
Re: Tuning Opal Optimizations
|
|
Hi Sven,
On Wed, Nov 20, 2013 at 11:33 AM, Sven Van Caekenberghe <[hidden email]> wrote:
It's an example. In real use you'd cache the translation dictionary in a variable, likely a class variable. See Clément's reply; thats exactly what he did. cheers!
best, Eliot
|
Re: Tuning Opal Optimizations
|
|
In reply to this post by Marcus Denker-4
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <[hidden email]> wrote: >> >> Yes, you can do it per class-hierarchy… you can implement on the class side a method to parametrize the compiler: >> >> compiler >> ^super compiler options: #(- optionInlineTimesRepeat) > > Thanks, Marcus, that works just great. Marcus, Are we sure this option mechanism works when loading code through Monticello ? I mean, this build fails the PEGParser tests: https://ci.inria.fr/pharo-contribution/job/Xtreams/ but it includes the #compiler options in Xtreams-Parsing-nice.7 Could it not be that this is a chicken-egg problem: the #compiler options are only there _after_ the class is loaded/compiled, or maybe it is an instance/class side problem ? Sven |
Re: Tuning Opal Optimizations
|
|
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <[hidden email]> wrote: > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <[hidden email]> wrote: > >>> >>> Yes, you can do it per class-hierarchy… you can implement on the class side a method to parametrize the compiler: >>> >>> compiler >>> ^super compiler options: #(- optionInlineTimesRepeat) >> >> Thanks, Marcus, that works just great. > > Marcus, > > Are we sure this option mechanism works when loading code through Monticello ? > No… we should make sure that MC loads the method first. I think it does that for #compilerClass already (but not sure). > I mean, this build fails the PEGParser tests: > > https://ci.inria.fr/pharo-contribution/job/Xtreams/ > > but it includes the #compiler options in Xtreams-Parsing-nice.7 > > Could it not be that this is a chicken-egg problem: the #compiler options are only there _after_ the class is loaded/compiled, or maybe it is an instance/class side problem ? > > Sven > > |
|
|
In reply to this post by Sven Van Caekenberghe-2
This mechanism does not work with Monticello. On my builds I have for this case something similar to: ./pharo $JOB_NAME.image config $REPO ConfigurationOfMyProject --install=bleedingEdge
./pharo $JOB_NAME.image eval --save 'SmalltalkImage compilerClass: OpalCompiler. Compiler recompileAll.' 2013/11/21 Sven Van Caekenberghe <[hidden email]>
|
|
|
In reply to this post by Marcus Denker-4
On 21 November 2013 12:30, Marcus Denker <[hidden email]> wrote:
which is still doesn't eliminates problem completely, because nothing prevents me from having: compilerClass ^ self otherMethod and now in order to work, MC have to know somehow that #otherMethod should also be loaded first. But i think some prioritization guarantees would be really useful. At least i think we can easily prioritize class-side compilation over instance side. Like that, when you compiling any of instance-side method, you know that class side is already there (and can be used as such in different kinds of hooks).
-- Best regards, Igor Stasenko. |
Re: Tuning Opal Optimizations
|
|
On 21 Nov 2013, at 15:55, Igor Stasenko <[hidden email]> wrote:
yes, we need atomic code loading. Marcus
|
Re: Tuning Opal Optimizations
|
|
What about having a configuration with a prerequisite package setting up
options ? Or optimisation tuning in one of the preload script of the package ? We already have ways to tune that; wouldn't they be better than setting a not so clear class before instance ordering (and what if the class itself requires that kind of tuning?). Thierry Le 21/11/2013 16:15, Marcus Denker a écrit : > > On 21 Nov 2013, at 15:55, Igor Stasenko <[hidden email] > <mailto:[hidden email]>> wrote: > >> >> >> >> On 21 November 2013 12:30, Marcus Denker <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> >> On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> > >> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <[hidden email] >> <mailto:[hidden email]>> wrote: >> > >> >>> >> >>> Yes, you can do it per class-hierarchy… you can implement on >> the class side a method to parametrize the compiler: >> >>> >> >>> compiler >> >>> ^super compiler options: #(- optionInlineTimesRepeat) >> >> >> >> Thanks, Marcus, that works just great. >> > >> > Marcus, >> > >> > Are we sure this option mechanism works when loading code >> through Monticello ? >> > >> >> No… we should make sure that MC loads the method first. I think it >> does that for #compilerClass >> already (but not sure). >> >> >> which is still doesn't eliminates problem completely, because nothing >> prevents me from having: >> >> compilerClass >> ^ self otherMethod >> >> and now in order to work, MC have to know somehow that #otherMethod >> should also be loaded first. >> But i think some prioritization guarantees would be really useful. >> At least i think we can easily prioritize class-side compilation over >> instance side. >> Like that, when you compiling any of instance-side method, you know >> that class side is already there (and can be used >> as such in different kinds of hooks). >> > > yes, we need atomic code loading. > > Marcus -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 |
|
|
On 21 November 2013 16:30, Goubier Thierry <[hidden email]> wrote: What about having a configuration with a prerequisite package setting up options ? Or optimisation tuning in one of the preload script of the package ? i doubt that there can be universal formal solution to this. We have to put some reasonable constraints into system, in order to be able to have a predictable behavior during boot-loading or bootstrapping. Or , somehow , package should carry enough metadata to tell system , in what order it must load things in it.. and problem obviously is wider than just order of compilation inside a single class, because it is just a part of bigger picture which is: - order or class loading and initialization i imagine that a complete (or say, most flexible) load order control must include class loading and class initialization e.g.:
load: ClassA , load:ClassB, init:ClassB, init:ClassA, load:ClassC Thierry -- Best regards, Igor Stasenko. |
Re: Tuning Opal Optimizations
|
|
Le 21/11/2013 16:37, Igor Stasenko a écrit : > > > > On 21 November 2013 16:30, Goubier Thierry <[hidden email] > <mailto:[hidden email]>> wrote: > > What about having a configuration with a prerequisite package > setting up options ? Or optimisation tuning in one of the preload > script of the package ? > > We already have ways to tune that; wouldn't they be better than > setting a not so clear class before instance ordering (and what if > the class itself requires that kind of tuning?). > > > i doubt that there can be universal formal solution to this. We have to > put some reasonable constraints into system, > in order to be able to have a predictable behavior during boot-loading > or bootstrapping. > Or , somehow , package should carry enough metadata to tell system , in > what order it must load things in it.. > and problem obviously is wider than just order of compilation inside a > single class, because it is just a part of bigger picture which is: > - order or class loading and initialization > > i imagine that a complete (or say, most flexible) load order control > must include class loading and class initialization e.g.: > > load: ClassA , load:ClassB, init:ClassB, init:ClassA, load:ClassC Of course, a perfect solution would be that, it would avoid seeing Undeclared stuff popping up when loading... I'd like an automatic way to load stuff so that even recursively dependent classes would not trigger any Undeclared stuff :) But, at the same time, if we have special requests, we can order them via package pre-requisites and preload scripts, isn't it? Thierry > Thierry > > Le 21/11/2013 16:15, Marcus Denker a écrit : > > > On 21 Nov 2013, at 15:55, Igor Stasenko <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > > > > On 21 November 2013 12:30, Marcus Denker > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>__>> wrote: > > > On 21 Nov 2013, at 11:34, Sven Van Caekenberghe > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > > > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > > >>> > >>> Yes, you can do it per class-hierarchy… you can > implement on > the class side a method to parametrize the compiler: > >>> > >>> compiler > >>> ^super compiler options: #(- > optionInlineTimesRepeat) > >> > >> Thanks, Marcus, that works just great. > > > > Marcus, > > > > Are we sure this option mechanism works when loading code > through Monticello ? > > > > No… we should make sure that MC loads the method first. > I think it > does that for #compilerClass > already (but not sure). > > > which is still doesn't eliminates problem completely, > because nothing > prevents me from having: > > compilerClass > ^ self otherMethod > > and now in order to work, MC have to know somehow that > #otherMethod > should also be loaded first. > But i think some prioritization guarantees would be really > useful. > At least i think we can easily prioritize class-side > compilation over > instance side. > Like that, when you compiling any of instance-side method, > you know > that class side is already there (and can be used > as such in different kinds of hooks). > > > yes, we need atomic code loading. > > Marcus > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Systèmes Temps Réel Embarqués > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 > <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 > > > > > -- > Best regards, > Igor Stasenko. -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 |
Re: Tuning Opal Optimizations
|
|
In reply to this post by Clément Béra
On 21 Nov 2013, at 12:30, Clément Bera <[hidden email]> wrote: > This mechanism does not work with Monticello. > > On my builds I have for this case something similar to: > > > ./pharo $JOB_NAME.image config $REPO ConfigurationOfMyProject --install=bleedingEdge > ./pharo $JOB_NAME.image eval --save 'SmalltalkImage compilerClass: OpalCompiler. Compiler recompileAll.’ Thanks, Clément, that works. I now do a ./pharo $JOB_NAME.image eval --save 'PEGParser recompile.’ so that OPAL picks up the options. > 2013/11/21 Sven Van Caekenberghe <[hidden email]> > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <[hidden email]> wrote: > > >> > >> Yes, you can do it per class-hierarchy… you can implement on the class side a method to parametrize the compiler: > >> > >> compiler > >> ^super compiler options: #(- optionInlineTimesRepeat) > > > > Thanks, Marcus, that works just great. > > Marcus, > > Are we sure this option mechanism works when loading code through Monticello ? > > I mean, this build fails the PEGParser tests: > > https://ci.inria.fr/pharo-contribution/job/Xtreams/ > > but it includes the #compiler options in Xtreams-Parsing-nice.7 > > Could it not be that this is a chicken-egg problem: the #compiler options are only there _after_ the class is loaded/compiled, or maybe it is an instance/class side problem ? > > Sven > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |