[Pharo-dev] Tuning Opal Optimizations

Goubier Thierry thierry.goubier at cea.fr
Thu Nov 21 10:51:18 EST 2013



Le 21/11/2013 16:37, Igor Stasenko a écrit :
>
>
>
> On 21 November 2013 16:30, Goubier Thierry <thierry.goubier at cea.fr
> <mailto:thierry.goubier at 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 at gmail.com
>         <mailto:siguctua at gmail.com>
>         <mailto:siguctua at gmail.com <mailto:siguctua at gmail.com>>> wrote:
>
>
>
>
>             On 21 November 2013 12:30, Marcus Denker
>             <marcus.denker at inria.fr <mailto:marcus.denker at inria.fr>
>             <mailto:marcus.denker at inria.fr
>             <mailto:marcus.denker at inria.fr>__>> wrote:
>
>
>                  On 21 Nov 2013, at 11:34, Sven Van Caekenberghe
>             <sven at stfx.eu <mailto:sven at stfx.eu>
>                  <mailto:sven at stfx.eu <mailto:sven at stfx.eu>>> wrote:
>
>                  >
>                  > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe
>             <sven at stfx.eu <mailto:sven at stfx.eu>
>                  <mailto:sven at stfx.eu <mailto:sven at 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




More information about the Pharo-dev mailing list