Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:
Hi, What about postponing this dicussion to the week of the 7th of march? This will be far easier... (and I really did not have the energy to follow this discussion. Most of the emails in this thread I did not read). Marcus On Feb 16, 2011, at 12:12 PM, Stéphane Ducasse wrote:
On Feb 16, 2011, at 6:12 PM, Eliot Miranda wrote:
On Tue, Feb 15, 2011 at 11:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: But it looks like a DSL to me.
No its not. caseOf: is valid Smalltalk. It is another control structure defined in the library rather than by the language, just like do:, inject:into: et al. It is extremely useful in certain circumstances. It can be (and is) optimized. Functional languages support case statements that are conceptually similar. caseOf: (and those of functional languages) are *much* more powerful than the switch statement of C: caseOf: can dispatch on arbitrary values, not just integer indices; caseOf:'s selectors (the things on the left of the ->'s) can be expressions, not just constants.
So caseOf: could be moved to Cog.
Fine. Let me be equally pig-headed then. I'm not going to spend any more energy on this, and I'm not going to spend any more energy on Cog in Pharo. This is ridiculous.
Then perfect be mad at me and take all the pharoers in prison. This is the only solution. Since you have the power to do it and I cannot do anything about it. I let you choose if I'm a real assshole, a plain idiot or just that I suggest something to ease our future. what I suggest is to - stop inlining caeOf so that the transition path to OPAL is easier - let caseOf use for VMMaker.
It would take 15 min to do that and probably 30 min to fix tools that are using caseOf: out of VMMaker.
Stef
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
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. Stef On Feb 16, 2011, at 9:23 PM, Marcus Denker wrote:
Hi,
What about postponing this dicussion to the week of the 7th of march? This will be far easier... (and I really did not have the energy to follow this discussion. Most of the emails in this thread I did not read).
Marcus
On Feb 16, 2011, at 12:12 PM, Stéphane Ducasse wrote:
On Feb 16, 2011, at 6:12 PM, Eliot Miranda wrote:
On Tue, Feb 15, 2011 at 11:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: But it looks like a DSL to me.
No its not. caseOf: is valid Smalltalk. It is another control structure defined in the library rather than by the language, just like do:, inject:into: et al. It is extremely useful in certain circumstances. It can be (and is) optimized. Functional languages support case statements that are conceptually similar. caseOf: (and those of functional languages) are *much* more powerful than the switch statement of C: caseOf: can dispatch on arbitrary values, not just integer indices; caseOf:'s selectors (the things on the left of the ->'s) can be expressions, not just constants.
So caseOf: could be moved to Cog.
Fine. Let me be equally pig-headed then. I'm not going to spend any more energy on this, and I'm not going to spend any more energy on Cog in Pharo. This is ridiculous.
Then perfect be mad at me and take all the pharoers in prison. This is the only solution. Since you have the power to do it and I cannot do anything about it. I let you choose if I'm a real assshole, a plain idiot or just that I suggest something to ease our future. what I suggest is to - stop inlining caeOf so that the transition path to OPAL is easier - let caseOf use for VMMaker.
It would take 15 min to do that and probably 30 min to fix tools that are using caseOf: out of VMMaker.
Stef
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On Wed, Feb 16, 2011 at 12:31 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
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? Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users? Of course you don't. You are being ridiculous.
Stef
On Feb 16, 2011, at 9:23 PM, Marcus Denker wrote:
Hi,
What about postponing this dicussion to the week of the 7th of march? This will be far easier... (and I really did not have the energy to follow this discussion. Most of the emails in this thread I did not read).
Marcus
On Feb 16, 2011, at 12:12 PM, Stéphane Ducasse wrote:
On Feb 16, 2011, at 6:12 PM, Eliot Miranda wrote:
On Tue, Feb 15, 2011 at 11:17 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
But it looks like a DSL to me.
No its not. caseOf: is valid Smalltalk. It is another control structure defined in the library rather than by the language, just like do:, inject:into: et al. It is extremely useful in certain circumstances. It can be (and is) optimized. Functional languages support case statements that are conceptually similar. caseOf: (and those of functional languages) are *much* more powerful than the switch statement of C: caseOf: can dispatch on arbitrary values, not just integer indices; caseOf:'s selectors (the things on the left of the ->'s) can be expressions, not just constants.
So caseOf: could be moved to Cog.
Fine. Let me be equally pig-headed then. I'm not going to spend any more energy on this, and I'm not going to spend any more energy on Cog in Pharo. This is ridiculous.
Then perfect be mad at me and take all the pharoers in prison. This is the only solution. Since you have the power to do it and I cannot do anything about it. I let you choose if I'm a real assshole, a plain idiot or just that I suggest something to ease our future. what I suggest is to - stop inlining caeOf so that the transition path to OPAL is easier - let caseOf use for VMMaker.
It would take 15 min to do that and probably 30 min to fix tools that are using caseOf: out of VMMaker.
Stef
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On Wed, Feb 16, 2011 at 12:31 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: 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?
yes
Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users? Of course you don't. You are being ridiculous.
eliot the statistics are against you. Stef
Stef
On Feb 16, 2011, at 9:23 PM, Marcus Denker wrote:
Hi,
What about postponing this dicussion to the week of the 7th of march? This will be far easier... (and I really did not have the energy to follow this discussion. Most of the emails in this thread I did not read).
Marcus
On Feb 16, 2011, at 12:12 PM, Stéphane Ducasse wrote:
On Feb 16, 2011, at 6:12 PM, Eliot Miranda wrote:
On Tue, Feb 15, 2011 at 11:17 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: But it looks like a DSL to me.
No its not. caseOf: is valid Smalltalk. It is another control structure defined in the library rather than by the language, just like do:, inject:into: et al. It is extremely useful in certain circumstances. It can be (and is) optimized. Functional languages support case statements that are conceptually similar. caseOf: (and those of functional languages) are *much* more powerful than the switch statement of C: caseOf: can dispatch on arbitrary values, not just integer indices; caseOf:'s selectors (the things on the left of the ->'s) can be expressions, not just constants.
So caseOf: could be moved to Cog.
Fine. Let me be equally pig-headed then. I'm not going to spend any more energy on this, and I'm not going to spend any more energy on Cog in Pharo. This is ridiculous.
Then perfect be mad at me and take all the pharoers in prison. This is the only solution. Since you have the power to do it and I cannot do anything about it. I let you choose if I'm a real assshole, a plain idiot or just that I suggest something to ease our future. what I suggest is to - stop inlining caeOf so that the transition path to OPAL is easier - let caseOf use for VMMaker.
It would take 15 min to do that and probably 30 min to fix tools that are using caseOf: out of VMMaker.
Stef
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
A quick comment... This whole thing/discussion/war reminds me of the Squeak mailing list, long ago, in its worst days... Let's all take a deep breath for a second and put things in perspective : aren't we just talking about 2 (TWO) methods here? Is this a do-it-now-or-die type of decision? Can't we leave it as is for now and move onto something else ? Yes, Pharo aims at being a super-clean environment but there's enough crap still out there that we can surely delay that one (and think about it a little bit more) and clean something else! I guess that since I'm not a VM expert here, I'd have to rely on Eliot's suggestion and advice and knowledge. If he says it's a lot of work from a VM-building perspective, he must know what he's talking about. If he says it's a lot of work, he must mean "it's a lot of work". If he says it's *really* useful from a VM-building perspective, he must really "it's useful". He's built enough VMs in the past, he must know what he's talking about. Let's not allow this to become another "I-know-better-and-more-than-you" type of argument (or ad hominem attack) that flooded the Squeak mailing list a few years ago... My 2 cents. ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
On Feb 16, 2011, at 10:19 PM, Benoit St-Jean wrote:
A quick comment...
This whole thing/discussion/war reminds me of the Squeak mailing list, long ago, in its worst days... Let's all take a deep breath for a second and put things in perspective : aren't we just talking about 2 (TWO) methods here? Is this a do-it-now-or-die type of decision? Can't we leave it as is for now and move onto something else ? Yes, Pharo aims at being a super-clean environment but there's enough crap still out there that we can surely delay that one (and think about it a little bit more) and clean something else!
we will let them in. no stress. and we will see if opal will inline them. probably not.
I guess that since I'm not a VM expert here, I'd have to rely on Eliot's suggestion and advice and knowledge. If he says it's a lot of work from a VM-building perspective, he must know what he's talking about. If he says it's a lot of work, he must mean "it's a lot of work". If he says it's *really* useful from a VM-building perspective, he must really "it's useful". He's built enough VMs in the past, he must know what he's talking about.
Let's not allow this to become another "I-know-better-and-more-than-you" type of argument (or ad hominem attack) that flooded the Squeak mailing list a few years ago...
exact because if this is the case I will simply leave the smalltalk community for real and focus on my tiny but extremely fun research.
My 2 cents.
----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
Ok this is my last mail on that topic.
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 ] ])}.
Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users? Of course you don't. You are being ridiculous.
Now when opal will arrive people should be prepared that probably caseOf: will not be inlined. Stef
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.
 Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users?  Of course you don't.  You are being ridiculous.
Now when opal will arrive people should be prepared that probably caseOf: will not be inlined.
Stef
-- Best regards, Igor Stasenko AKA sig.
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 ;) Nicolas
 Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users?  Of course you don't.  You are being ridiculous.
Now when opal will arrive people should be prepared that probably caseOf: will not be inlined.
Stef
-- Best regards, Igor Stasenko AKA sig.
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?
Nicolas
-- Best regards, Igor Stasenko AKA sig.
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 ? Nicolas
Nicolas
-- Best regards, Igor Stasenko AKA sig.
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.
participants (6)
-
Benoit St-Jean -
Eliot Miranda -
Igor Stasenko -
Marcus Denker -
Nicolas Cellier -
Stéphane Ducasse