[Pharo-dev] Tuning Opal Optimizations

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 20 14:18:50 EST 2013


On Wed, Nov 20, 2013 at 10:54 AM, Clément Bera <bera.clement at gmail.com>wrote:

> 2013/11/20 Eliot Miranda <eliot.miranda at gmail.com>
>
>>
>> On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> 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.
>>
>
> 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.
>

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


>
>>
>> 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 <siguctua at gmail.com>
>>>
>>>>
>>>>
>>>>
>>>> On 19 November 2013 16:20, Marcus Denker <marcus.denker at inria.fr>wrote:
>>>>
>>>>>
>>>>> On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven at stfx.eu> 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
>>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131120/6649e1b1/attachment-0002.html>


More information about the Pharo-dev mailing list