On 17 February 2011 01:28, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2011/2/17 Igor Stasenko <siguctua@gmail.com>:
On 17 February 2011 00:51, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2011/2/17 Igor Stasenko <siguctua@gmail.com>:
On 16 February 2011 22:00, Stéphane Ducasse <stephane.ducasse@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.