[Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko siguctua at gmail.com
Thu Feb 17 02:22:32 CET 2011


On 17 February 2011 01:28, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2011/2/17 Igor Stasenko <siguctua at gmail.com>:
>> On 17 February 2011 00:51, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> 2011/2/17 Igor Stasenko <siguctua at gmail.com>:
>>>> On 16 February 2011 22:00, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>>>>> Ok this is my last mail on that topic.
>>>>>
>>>>
>>>> apparently not ;)
>>>>
>>>>>
>>>>>> yes now do not think that I'm implying that you are not able to implement a decompiler.
>>>>>> Now we have something else to do that dealing with the optimisation of a stupid method.
>>>>>> This is all my point.
>>>>>> Let us focus on the real problems. eliot is crying for caseOf: but we have 3 users.
>>>>>>
>>>>>> Did you know that there are several uses of caseOf: in the Opal compiler?
>>>>>
>>>>>
>>>>> (selector := aMessageNode selector)
>>>>>                caseOf:
>>>>>                        {([ #ifNil: ]
>>>>>                                -> [ self isValueTranslator ifTrue: [ methodBuilder pushDup ] ]).
>>>>>                        ([ #ifNil:ifNotNil: ]
>>>>>                                -> [ args last arguments ifNotEmpty: [ args last arguments first binding emitStore: methodBuilder ] ]).
>>>>>                        ([ #ifNotNil: ]
>>>>>                                -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]).
>>>>>                        ([ #ifNotNilDo: ]
>>>>>                                -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]).
>>>>>                        ([ #ifNotNil:ifNil: ]
>>>>>                                -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ])}.
>>>>>
>>>>>
>>>>
>>>> yikes... so Opal already polluted (as being non-pure) by premature
>>>> optimizations :)
>>>>
>>>> You see the tendency: one premature optimization drags other after itself.
>>>>
>>>> I would suggest to make full & working compiler suite which doing no
>>>> any optimizations/inlining,
>>>> and only then, when everything works, add a code with inlining
>>>> optimizations as a plugin.
>>>> So, people will know, that this is _optional_ not mandatory and not
>>>> hardwired into smalltalk compiler.
>>>> This is the message a good compiler should pass to developers:
>>>> optimizations are useful but not essential.
>>>> But i am not analyzed Opal code deeply, maybe its already like that.
>>>>
>>>>
>>>
>>> Sure, if it's just a proof of concept.... but wasting 10x factor when
>>> Eliot spent so many efforts to gain 3x would sound like a denial of
>>> his own utility in this community.
>>> I can understand his reticence quite easily ;)
>>
>> I see it like following:
>>  - VM gets faster so language side could drop hacky optimizations
>>
>> For instance, why #class or #== messages are early bound? What is a
>> tradeoff for having 0.005% faster system,
>> but unable to have good proxies?
>>
>> As Eliot said before: you can cheat, but don't get caught. Apparently
>> things like above didn't took that into account. So why we should not
>> attempt to fix that?
>>
>
> I see, pas de vache sacrée ;)
> But I thought you were speaking of Opal Compiler inlining hacks.
> Are above features Compiler optimizations or VM optimizations ?
>
both. there is a bytecode which used for sends which bypassing lookup procedure.
and compiler which generates them :)

> Nicolas
>
>>>
>>> Nicolas
>>>
>>>>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list