Re: [Pharo-dev] Tuning Opal Optimizations
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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).
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
-- Best regards, Igor Stasenko.
On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
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 <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> 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 <thierry.goubier@cea.fr> 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
Thierry
Le 21/11/2013 16:15, Marcus Denker a écrit :
On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> 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
-- Best regards, Igor Stasenko.
Le 21/11/2013 16:37, Igor Stasenko a écrit :
On 21 November 2013 16:30, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> 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 <siguctua@gmail.com <mailto:siguctua@gmail.com> <mailto:siguctua@gmail.com <mailto:siguctua@gmail.com>>> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr> <mailto:marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>__>> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu> <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>> wrote:
> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu> <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>> 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
I fail to see what atomic means in this context, it's too broad idea. To me atomic would be: compile all in a certain sequence, then install all at once atomically. And in this case, there is still a problem, because it would resolve installation order, not compilation order... The idea of compiling class side first sounds good to me. It's not atomic, but might just work. 2013/11/21 Marcus Denker <marcus.denker@inria.fr>
On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
Of course, if someone has stupid idea to define Object>>compiler, then it's not on class side, but should be compiled first :( 2013/11/21 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
I fail to see what atomic means in this context, it's too broad idea. To me atomic would be: compile all in a certain sequence, then install all at once atomically. And in this case, there is still a problem, because it would resolve installation order, not compilation order...
The idea of compiling class side first sounds good to me. It's not atomic, but might just work.
2013/11/21 Marcus Denker <marcus.denker@inria.fr>
On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
On 21 November 2013 19:59, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I fail to see what atomic means in this context, it's too broad idea. To me atomic would be: compile all in a certain sequence, then install all at once atomically. And in this case, there is still a problem, because it would resolve installation order, not compilation order...
The idea of compiling class side first sounds good to me. It's not atomic, but might just work.
right, i also don't see how atomic installation helps in that regard. besides that such mechanism implies that it is not atomic, because first you have to compile and install #compilerClass method, and only then compile and install rest. because if it will be done in one atomic step, it either won't work or work incorrectly.
2013/11/21 Marcus Denker <marcus.denker@inria.fr>
On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
-- Best regards, Igor Stasenko.
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 <sven@stfx.eu>
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
On 21 Nov 2013, at 12:30, Clément Bera <bera.clement@gmail.com> 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 <sven@stfx.eu>
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu> 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
participants (6)
-
Clément Bera -
Goubier Thierry -
Igor Stasenko -
Marcus Denker -
Nicolas Cellier -
Sven Van Caekenberghe