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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Feb 17 01:28:26 CET 2011


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 ?

Nicolas

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




More information about the Pharo-project mailing list