could we agree to remove caseOf: and caseOf:otherwise:
Locked
12345
12345
Re: could we agree to remove caseOf: and caseOf:otherwise:
 
|
On Feb 16, 2011, at 6:12 PM, Eliot Miranda wrote: > > > On Tue, Feb 15, 2011 at 11:17 PM, Stéphane Ducasse <[hidden email]> 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 |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Igor Stasenko
Igor
my point is how can we migrate from the old compiler to the new one that will probably not support inlining of caseOf: if we rely or have caseOf: in the old compiler. If we do not need case of inlining then we can remove it and we can also clean Object. Stef On Feb 16, 2011, at 6:42 PM, Igor Stasenko wrote: > On 16 February 2011 18:15, Eliot Miranda <[hidden email]> wrote: >> >> >> On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse >> <[hidden email]> wrote: >>> >>> Eliot a final question. >>> So how will you handle OPAL compiler change in Cog? >>> Do you require that marcus and jorge have to deal with decompiler of >>> caseOf: in addition to all the rest? >>> Is it a strong requirement? Because then this is clear that Opal will be >>> delayed. But may be it is not that important after all. >>> Just curious. >> >> OPAL is a Smalltalk compiler. I can therefore assume that it will compile >> Smalltalk. caseOf: is valid Smalltalk and so will be compiled by OPAL. >> Whether Marcus chooses to optimise caseOf: or not is up to him. > > And this was the question from the beginning of this thread :) > Except that not all realized that Stef were talking about new compiler (Opal), > not existing one. > I am perfectly fine with current state of Compiler.. and it is really > not worth adding/removing something from it, > because in Pharo plans to integrate new compiler infrastructure. > So, it is obvious that any work on old compiler is a waste of time and energy. > > >>> >>> Stef >>> (if you think that I focus on details then I'm certainly an idiot). >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Stéphane Ducasse
On Wed, Feb 16, 2011 at 12:04 PM, Stéphane Ducasse <[hidden email]> wrote:
No it's not. Your point was to raise two straw-=man arguments: 1. that Marcus and Jorge would have to deal with the decompiler (not an issue; the decompiler already deals with optimized caseOf: and the new decompiler will deal with optimized caseOf: just as it'll deal with optimized ifTrue: ifNotNil: et al).
2. that supporting caseOf: in optimized form will delay Opal (not an issue; Opal will optimize certain constructs, this is just one more and won't add a lot of time). So your point appears to be to try and justify removing caseOf: on spurious grounds by spreading FUD.
This is so unlike you I'm having a hard time really understanding what's going on. best regards, Eliot
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
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 <[hidden email]> 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. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
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 <[hidden email]> 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. > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Wed, Feb 16, 2011 at 12:31 PM, Stéphane Ducasse <[hidden email]> wrote: yes now do not think that I'm implying that you are not able to implement a decompiler. 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.
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
> > On Wed, Feb 16, 2011 at 12:31 PM, Stéphane Ducasse <[hidden email]> 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 <[hidden email]> 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. > > > > > > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
On Feb 16, 2011, at 12:57 PM, Stéphane Ducasse wrote: > >> >> On Wed, Feb 16, 2011 at 12:31 PM, Stéphane Ducasse <[hidden email]> 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. Can we postpone this discussion? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
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 |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Stéphane Ducasse
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) |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
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) > > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Marcus Denker-4
On 16 February 2011 21:59, Marcus Denker <[hidden email]> wrote:
> > On Feb 16, 2011, at 12:57 PM, Stéphane Ducasse wrote: > >> >>> >>> On Wed, Feb 16, 2011 at 12:31 PM, Stéphane Ducasse <[hidden email]> 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. > > Can we postpone this discussion? > yeah guys.. lower the level of emotions. No need to become mad and make new enemies. Because most of the times people regret about it after, but its too late to fix what was broken. I am really surprised that such minor issue attracted so much attention.. (yes yes, i am guilty for pouring oil to flames.. ) > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Stéphane Ducasse
On 16 February 2011 22:00, Stéphane Ducasse <[hidden email]> 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. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
2011/2/17 Igor Stasenko <[hidden email]>:
> On 16 February 2011 22:00, Stéphane Ducasse <[hidden email]> 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. > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On 17 February 2011 00:51, Nicolas Cellier
<[hidden email]> wrote: > 2011/2/17 Igor Stasenko <[hidden email]>: >> On 16 February 2011 22:00, Stéphane Ducasse <[hidden email]> 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. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
2011/2/17 Igor Stasenko <[hidden email]>:
> On 17 February 2011 00:51, Nicolas Cellier > <[hidden email]> wrote: >> 2011/2/17 Igor Stasenko <[hidden email]>: >>> On 16 February 2011 22:00, Stéphane Ducasse <[hidden email]> 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. > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On 17 February 2011 01:28, Nicolas Cellier
<[hidden email]> wrote: > 2011/2/17 Igor Stasenko <[hidden email]>: >> On 17 February 2011 00:51, Nicolas Cellier >> <[hidden email]> wrote: >>> 2011/2/17 Igor Stasenko <[hidden email]>: >>>> On 16 February 2011 22:00, Stéphane Ducasse <[hidden email]> 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 ? > and compiler which generates them :) > Nicolas > >>> >>> Nicolas >>> >>>>> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Eliot Miranda-2
Correct me if I'm wrong but isn't Stephane essentially saying that Opal will just demote #caseOf: from inlined special form to normal method? (Possibly so it can be unloadable instead of being pinned in the system by the compiler support). It seems to me that this shouldn't affect caseOf: use in Cog since the inlining there is handled by the SLang translator. Or have I totally misunderstood? Of course, where caseOf: is kept afterwards another question :) |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Thu, Feb 17, 2011 at 1:59 AM, Douglas Brebner <[hidden email]> wrote:
It certainly won't affect the production Cog since indeed that goes through Slang to emerge as C. However it will affect developing in Cog, which is done by rnning the simulator, and as I've shown case statements are used in some performance-critical parts of the system (byte access).
I don't see why one would want to get rid of this useful functionality. There is nothing inherrently wrong with a flexible case statement. Its certainly far more preferrable than a performance-equivalent set of nested ifTrue:ifFalse:'s. Further, the dictionary/perform or multiple classes approaches only make sense at a certain scale (that's especially true of the dictionary/perform alternative since maintaining the dictionary is painful). So for me it makes absolutely no sense for a Squeak-derived Smalltalk dialect to eliminate a construct that is really useful in certain circumstances. That kind of thinking eliminates things like contexts and that's a slippery slope to eliminating the essential flexibility of the system.
2¢ Eliot |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
Wasn't there mention of Opal having optimisations as extensions so you can have an optimised caseOf: without having it hardwired into the compiler? I wasn't arguing for getting rid of it entirely, I prefer it to dictionary/perform which I dislike for some reason |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |