[Pharo-dev] Tuning Opal Optimizations

Igor Stasenko siguctua at gmail.com
Thu Nov 21 10:37:04 EST 2013


On 21 November 2013 16:30, Goubier Thierry <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



> 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>> wrote:
>>
>>
>>>
>>>
>>> On 21 November 2013 12:30, Marcus Denker <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>> wrote:
>>>
>>>     >
>>>     > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <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 / 83 95
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131121/b7983507/attachment-0002.html>


More information about the Pharo-dev mailing list