could we agree to remove caseOf: and caseOf:otherwise:
Locked
12345
12345
could we agree to remove caseOf: and caseOf:otherwise:
 
|
Hi guys
let us do another pass at cleaning and realigning the system. Could we agree to deprecate caseOf: and caseOf:otherwise:? it will simply the compiler, decompiler and also we do not need that at all. | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z => "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. z detect: [:each | each key value = #b] " there is one user which I fixing right now. Stef |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Fri, 11 Feb 2011, stephane ducasse wrote:
> Hi guys > > let us do another pass at cleaning and realigning the system. > Could we agree to deprecate caseOf: and caseOf:otherwise:? > it will simply the compiler, decompiler and also we do not need that at all. > > | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z > > => > "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. > z detect: [:each | each key value = #b] " > > there is one user which I fixing right now. IMHO you shouldn't remove it. There are a lot more users of this method (16 in the Pharo image I have and a lot more in external packages), but this method is inlined by the compiler, so you won't see it in the senders list. Try this instead: SystemNavigation default browseMethodsWithSourceString: 'caseOf:'. Using #detect: and #detect:ifNone: with a dynamically created array is a _lot_ slower than the inlined #caseOf: and #caseOf:otherwise:. For example: [ 1 to: 10 do: [ :each | each caseOf: { [ 1 ] -> [ $a ]. [ 2 ] -> [ $b ]. [ 3 ] -> [ $c ]. [ 4 ] -> [ $d ]. [ 5 ] -> [ $e ] } otherwise: [ $x ] ] ] bench. '1,790,000 per second.'. [ 1 to: 10 do: [ :each | ({ [ 1 ] -> [ $a ]. [ 2 ] -> [ $b ]. [ 3 ] -> [ $c ]. [ 4 ] -> [ $d ]. [ 5 ] -> [ $e ] } detect: [ :ea | ea key value = each ] ifNone: [ [ $x ] ]) value ] ] bench. '66,600 per second.' ~27x slowdown in this case. Levente |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On 12 February 2011 18:41, Levente Uzonyi <[hidden email]> wrote:
> On Fri, 11 Feb 2011, stephane ducasse wrote: > >> Hi guys >> >> let us do another pass at cleaning and realigning the system. >> Could we agree to deprecate caseOf: and caseOf:otherwise:? >> it will simply the compiler, decompiler and also we do not need that at >> all. >> >> | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z >> >> => >> "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. >> z detect: [:each | each key value = #b] " >> >> there is one user which I fixing right now. > > IMHO you shouldn't remove it. There are a lot more users of this method (16 > in the Pharo image I have and a lot more in external packages), but this > method is inlined by the compiler, so you won't see it in the senders list. > Try this instead: > > SystemNavigation default browseMethodsWithSourceString: 'caseOf:'. > > Using #detect: and #detect:ifNone: with a dynamically created array is a > _lot_ slower than the inlined #caseOf: and #caseOf:otherwise:. For example: > > [ 1 to: 10 do: [ :each | > each > caseOf: { > [ 1 ] -> [ $a ]. > [ 2 ] -> [ $b ]. > [ 3 ] -> [ $c ]. > [ 4 ] -> [ $d ]. > [ 5 ] -> [ $e ] } > otherwise: [ $x ] ] ] bench. > '1,790,000 per second.'. > > [ 1 to: 10 do: [ :each | > ({ > [ 1 ] -> [ $a ]. > [ 2 ] -> [ $b ]. > [ 3 ] -> [ $c ]. > [ 4 ] -> [ $d ]. > [ 5 ] -> [ $e ] } > detect: [ :ea | ea key value = each ] > ifNone: [ [ $x ] ]) value ] ] bench. > '66,600 per second.' > > ~27x slowdown in this case. > oh come on. Switch statement should live where it belongs to: C code. Why we should support this ridiculous syntax constructs in smalltalk? IMO: All users of such code should die. And i don't care if they are working fast or not.. This is plainly against the spirit of smalltalk. > > Levente > > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Sat, 12 Feb 2011, Igor Stasenko wrote:
> oh come on. Switch statement should live where it belongs to: C code. It's nothing like C's switch statement, and I'm sure you know that. > > Why we should support this ridiculous syntax constructs in smalltalk? What's so ridiculous about it? > IMO: > All users of such code should die. And i don't care if they are > working fast or not.. > This is plainly against the spirit of smalltalk. Okay, then enlighten me please, how one should rewrite the following dispatch without #caseOf:? You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a variable's value is equal to any of these, a predefined value has to be set to an instance variable depending on the integer. The current code is like: foo caseOf: { [ 0 ] -> [ var2 := x ]. [ 83 ] -> [ var13 := x ]. ... Should I use #detect: to find the variable? Or a dictionary? Maybe a binary search on an array? Or a bunch of #ifTrue:ifFalse: conditionals? Maybe a separate class for each variable and let the VM do the dispatch? How should I set the value? With #perform:? Or #instVarAt:put:? Levente > >> >> Levente >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On 13 February 2011 00:17, Levente Uzonyi <[hidden email]> wrote:
> On Sat, 12 Feb 2011, Igor Stasenko wrote: > >> oh come on. Switch statement should live where it belongs to: C code. > > It's nothing like C's switch statement, and I'm sure you know that. > >> >> Why we should support this ridiculous syntax constructs in smalltalk? > > What's so ridiculous about it? > >> IMO: >> All users of such code should die. And i don't care if they are >> working fast or not.. >> This is plainly against the spirit of smalltalk. > > Okay, then enlighten me please, how one should rewrite the following > dispatch without #caseOf:? > > You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a > variable's value is equal to any of these, a predefined value has to be set > to an instance variable depending on the integer. The current code is like: > > foo caseOf: { > [ 0 ] -> [ var2 := x ]. > [ 83 ] -> [ var13 := x ]. > ... > > Should I use #detect: to find the variable? Or a dictionary? Maybe a binary > search on an array? Or a bunch of #ifTrue:ifFalse: conditionals? Maybe a > separate class for each variable and let the VM do the dispatch? > How should I set the value? With #perform:? Or #instVarAt:put:? > Don't try to convince me that there are sort of problems which can be solved only by using case statement :) First, get rid of these integers in your code. Use symbolic names. And then for dispatching using parameter, there is a #peform: primitive. So, then switch statement will be turned into: self peform: (self decode: someInteger) and this is how it should look like. And again, if you can avoid using integers at all, use symbols , so you don't have to decode/translate them. Just do #perform. I thought that this is obvious for you. > > Levente > -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Sun, 13 Feb 2011, Igor Stasenko wrote:
> Don't try to convince me that there are sort of problems which can be > solved only by using case statement :) We all know that it can be solved, but the solution won't be nicer at all, instead it will be a lot slower. > First, get rid of these integers in your code. Use symbolic names. > And then for dispatching using parameter, there is a #peform: primitive. The integers are from a binary stream, so I can't do much about it. > > So, then switch statement will be turned into: > > self peform: (self decode: someInteger) > > and this is how it should look like. > And again, if you can avoid using integers at all, use symbols , so > you don't have to decode/translate them. > Just do #perform. > > I thought that this is obvious for you. What you wrote here is obvious, but not an answer to my question. What should #decode: do? Use #detect:? Or a dictionary? Maybe a binary search on an array? Or should it be a bunch of #ifTrue:ifFalse: conditionals? (I guess the separate class per integer idea is abandoned, but who knows.) Also note that #perform:with: is ~11x slower on Cog than sending a message. And a send is a lot slower (~5.5x IIRC) than a direct assignment. That's ~55x combined slowdown not counting the integer->selector matching. Levente > >> >> Levente >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On 13 February 2011 00:59, Levente Uzonyi <[hidden email]> wrote:
> On Sun, 13 Feb 2011, Igor Stasenko wrote: > >> Don't try to convince me that there are sort of problems which can be >> solved only by using case statement :) > > We all know that it can be solved, but the solution won't be nicer at all, > instead it will be a lot slower. > >> First, get rid of these integers in your code. Use symbolic names. >> And then for dispatching using parameter, there is a #peform: primitive. > > The integers are from a binary stream, so I can't do much about it. > >> >> So, then switch statement will be turned into: >> >> self peform: (self decode: someInteger) >> >> and this is how it should look like. >> And again, if you can avoid using integers at all, use symbols , so >> you don't have to decode/translate them. >> Just do #perform. >> >> I thought that this is obvious for you. > > What you wrote here is obvious, but not an answer to my question. What > should #decode: do? Use #detect:? Or a dictionary? Maybe a binary search on > an array? Or should it be a bunch of #ifTrue:ifFalse: conditionals? (I guess > the separate class per integer idea is abandoned, but who knows.) > Use bare numbers without any docs/comments/explanations to C. > Also note that #perform:with: is ~11x slower on Cog than sending a message. > And a send is a lot slower (~5.5x IIRC) than a direct assignment. That's > ~55x combined slowdown not counting the integer->selector matching. > Slower comparing to someone who will read your code and try to understand what it does. THAT WILL BE SLOWER and that is most precious resource we have, not the CPU time. Please read the http://www.c2.com/cgi/wiki?PrematureOptimization :) > > Levente > >> -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Sun, 13 Feb 2011, Igor Stasenko wrote:
> On 13 February 2011 00:59, Levente Uzonyi <[hidden email]> wrote: >> On Sun, 13 Feb 2011, Igor Stasenko wrote: >> >>> Don't try to convince me that there are sort of problems which can be >>> solved only by using case statement :) >> >> We all know that it can be solved, but the solution won't be nicer at all, >> instead it will be a lot slower. >> >>> First, get rid of these integers in your code. Use symbolic names. >>> And then for dispatching using parameter, there is a #peform: primitive. >> >> The integers are from a binary stream, so I can't do much about it. >> > Oh yeah? Too bad for you then. And everyone trying to implement a binary protocol efficiently. > >>> >>> So, then switch statement will be turned into: >>> >>> self peform: (self decode: someInteger) >>> >>> and this is how it should look like. >>> And again, if you can avoid using integers at all, use symbols , so >>> you don't have to decode/translate them. >>> Just do #perform. >>> >>> I thought that this is obvious for you. >> >> What you wrote here is obvious, but not an answer to my question. What >> should #decode: do? Use #detect:? Or a dictionary? Maybe a binary search on >> an array? Or should it be a bunch of #ifTrue:ifFalse: conditionals? (I guess >> the separate class per integer idea is abandoned, but who knows.) >> > I don't care. You should encapsulate them into something , which has a meaning. > Use bare numbers without any docs/comments/explanations to C. > >> Also note that #perform:with: is ~11x slower on Cog than sending a message. >> And a send is a lot slower (~5.5x IIRC) than a direct assignment. That's >> ~55x combined slowdown not counting the integer->selector matching. >> > Slower comparing to someone who will read your code and try to > understand what it does. > THAT WILL BE SLOWER and that is most precious resource we have, not > the CPU time. Is #caseOf: unreadable? No it's not. You just don't like it for some unknown reason. And you're not willing to tell what's your problem with it. > > Please read the > http://www.c2.com/cgi/wiki?PrematureOptimization > :) I know what's premature optimization. What I do differently than other people (including you) is: - if I can choose from different solutions for some problem, then I usually pick the one with the best expected performance if it has neglible other extra cost (complexity, readability, size, etc) compared to other solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:, foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil ifFalse: [ ... ]), etc. - I optimize library code which is expected to be heavily used - I like to optimize code Levente > >> >> Levente >> >>> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
El dom, 13-02-2011 a las 02:26 +0100, Levente Uzonyi escribió:
> I know what's premature optimization. It appear that you know but doesn't understand. See below. > What I do differently than other > people (including you) is: > - if I can choose from different solutions for some problem, then I > usually pick the one with the best expected performance if it has neglible > other extra cost (complexity, readability, size, etc) compared to other > solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:, > foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil > ifFalse: [ ... ]), etc. This *is* premature optimization. Why? because you're programming with the performance in mind *all* the time, since the first second you start programming! And not only that, it relies on a specific VM implementation, the squeak one. Presumes that the given messages are *more efficient* (just because you know that the squeak compiler/vm combination makes them so). But this could be wrong or at least useless in other vm (like GNU or Gemstone). So by definition it is premature optimization. Lastly, to program like you (and not like others, Igor and I and most people I think) we should have in the head the specifics of the vm implementation and a handy list of the inlined messages of the vm. This is the job of the JIT, not from the developer! > - I optimize library code which is expected to be heavily used This the time and usage will tell > - I like to optimize code Prematurely it appears! Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Levente Uzonyi-2
On 13 February 2011 02:26, Levente Uzonyi <[hidden email]> wrote:
> On Sun, 13 Feb 2011, Igor Stasenko wrote: > >> On 13 February 2011 00:59, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Sun, 13 Feb 2011, Igor Stasenko wrote: >>> >>>> Don't try to convince me that there are sort of problems which can be >>>> solved only by using case statement :) >>> >>> We all know that it can be solved, but the solution won't be nicer at >>> all, >>> instead it will be a lot slower. >>> >>>> First, get rid of these integers in your code. Use symbolic names. >>>> And then for dispatching using parameter, there is a #peform: primitive. >>> >>> The integers are from a binary stream, so I can't do much about it. >>> >> Oh yeah? Too bad for you then. > > And everyone trying to implement a binary protocol efficiently. > >> >>>> >>>> So, then switch statement will be turned into: >>>> >>>> self peform: (self decode: someInteger) >>>> >>>> and this is how it should look like. >>>> And again, if you can avoid using integers at all, use symbols , so >>>> you don't have to decode/translate them. >>>> Just do #perform. >>>> >>>> I thought that this is obvious for you. >>> >>> What you wrote here is obvious, but not an answer to my question. What >>> should #decode: do? Use #detect:? Or a dictionary? Maybe a binary search >>> on >>> an array? Or should it be a bunch of #ifTrue:ifFalse: conditionals? (I >>> guess >>> the separate class per integer idea is abandoned, but who knows.) >>> >> I don't care. You should encapsulate them into something , which has a >> meaning. >> Use bare numbers without any docs/comments/explanations to C. >> >>> Also note that #perform:with: is ~11x slower on Cog than sending a >>> message. >>> And a send is a lot slower (~5.5x IIRC) than a direct assignment. That's >>> ~55x combined slowdown not counting the integer->selector matching. >>> >> Slower comparing to someone who will read your code and try to >> understand what it does. >> THAT WILL BE SLOWER and that is most precious resource we have, not >> the CPU time. > > Is #caseOf: unreadable? No it's not. You just don't like it for some unknown > reason. And you're not willing to tell what's your problem with it. > >> >> Please read the >> http://www.c2.com/cgi/wiki?PrematureOptimization >> :) > > I know what's premature optimization. What I do differently than other > people (including you) is: > - if I can choose from different solutions for some problem, then I usually > pick the one with the best expected performance if it has neglible other > extra cost (complexity, readability, size, etc) compared to other solutions. > E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:, > foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil > ifFalse: [ ... ]), etc. > - I optimize library code which is expected to be heavily used > - I like to optimize code > You will discover something surprising for you. > > Levente > >> >>> >>> Levente >>> >>>> >> >> >> >> -- >> 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 Miguel Cobá
On Sat, 12 Feb 2011, Miguel Cobá wrote:
> El dom, 13-02-2011 a las 02:26 +0100, Levente Uzonyi escribió: > >> I know what's premature optimization. > > It appear that you know but doesn't understand. See below. > >> What I do differently than other >> people (including you) is: >> - if I can choose from different solutions for some problem, then I >> usually pick the one with the best expected performance if it has neglible >> other extra cost (complexity, readability, size, etc) compared to other >> solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:, >> foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil >> ifFalse: [ ... ]), etc. > > This *is* premature optimization. Why? because you're programming with > the performance in mind *all* the time, since the first second you start > programming! all. It has zero extra cost for you to read it, for me to write it, for the machine to execute it. > > And not only that, it relies on a specific VM implementation, the squeak > one. Presumes that the given messages are *more efficient* (just because > you know that the squeak compiler/vm combination makes them so). But > this could be wrong or at least useless in other vm (like GNU or > Gemstone). So by definition it is premature optimization. That's right, I don't care about other VMs. Do the developers of VW, Gemstone or GNU Smalltalk care about how their code will perform on SqueakVM or CogVM? Hardly. > > Lastly, to program like you (and not like others, Igor and I and most > people I think) we should have in the head the specifics of the vm > implementation and a handy list of the inlined messages of the vm. That list is surprisingly short. There are more keywords or syntax constructs in C/C++/Java/C#/Python/whatever than these special messages. > This is the job of the JIT, not from the developer! Show me the JIT that does it. Levente > > >> - I optimize library code which is expected to be heavily used > > This the time and usage will tell > > >> - I like to optimize code > > Prematurely it appears! > > Cheers > > -- > Miguel Cobá > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Igor Stasenko
On Sun, 13 Feb 2011, Igor Stasenko wrote:
> Please read the Ian's paper about switch statement vs message sends.. > You will discover something surprising for you. Link please? Levente > >> >> Levente >> >>> >>>> >>>> Levente >>>> >>>>> >>> >>> >>> >>> -- >>> 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 Levente Uzonyi-2
El dom, 13-02-2011 a las 02:58 +0100, Levente Uzonyi escribió:
> On Sat, 12 Feb 2011, Miguel Cobá wrote: > > > El dom, 13-02-2011 a las 02:26 +0100, Levente Uzonyi escribió: > > > >> I know what's premature optimization. > > > > It appear that you know but doesn't understand. See below. > > > >> What I do differently than other > >> people (including you) is: > >> - if I can choose from different solutions for some problem, then I > >> usually pick the one with the best expected performance if it has neglible > >> other extra cost (complexity, readability, size, etc) compared to other > >> solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:, > >> foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil > >> ifFalse: [ ... ]), etc. > > > > This *is* premature optimization. Why? because you're programming with > > the performance in mind *all* the time, since the first second you start > > programming! > > What you fail to realize is that the code is not longer or complicated at > all. It has zero extra cost for you to read it, for me to write it, for > the machine to execute it. > > > > > And not only that, it relies on a specific VM implementation, the squeak > > one. Presumes that the given messages are *more efficient* (just because > > you know that the squeak compiler/vm combination makes them so). But > > this could be wrong or at least useless in other vm (like GNU or > > Gemstone). So by definition it is premature optimization. > > That's right, I don't care about other VMs. Do the developers of VW, > Gemstone or GNU Smalltalk care about how their code will perform on > SqueakVM or CogVM? Hardly. > > > > > Lastly, to program like you (and not like others, Igor and I and most > > people I think) we should have in the head the specifics of the vm > > implementation and a handy list of the inlined messages of the vm. > > That list is surprisingly short. There are more keywords or syntax > constructs in C/C++/Java/C#/Python/whatever than these special messages. The list of registers in a intel 386 cpu is short too but that doesn't means that everyone must learn what registers are better for what kind of datatype performance-wise. Again this is not the task for the developer. As everyone trying to do OO programing, the implementation details are irrelevant when programming. > > > This is the job of the JIT, not from the developer! > > Show me the JIT that does it. I said that is the *job* of the JIT not that every JIT can do it/should do it/does it. > > > Levente > > > > > > >> - I optimize library code which is expected to be heavily used > > > > This the time and usage will tell > > > > > >> - I like to optimize code > > > > Prematurely it appears! > > > > Cheers > > > > -- > > Miguel Cobá > > http://twitter.com/MiguelCobaMtz > > http://miguel.leugim.com.mx > > > > > > > > > > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On Sat, 12 Feb 2011, Miguel Cobá wrote:
> El dom, 13-02-2011 a las 02:58 +0100, Levente Uzonyi escribió: >> On Sat, 12 Feb 2011, Miguel Cobá wrote: >> >>> El dom, 13-02-2011 a las 02:26 +0100, Levente Uzonyi escribió: >>> >>>> I know what's premature optimization. >>> >>> It appear that you know but doesn't understand. See below. >>> >>>> What I do differently than other >>>> people (including you) is: >>>> - if I can choose from different solutions for some problem, then I >>>> usually pick the one with the best expected performance if it has neglible >>>> other extra cost (complexity, readability, size, etc) compared to other >>>> solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:, >>>> foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil >>>> ifFalse: [ ... ]), etc. >>> >>> This *is* premature optimization. Why? because you're programming with >>> the performance in mind *all* the time, since the first second you start >>> programming! >> >> What you fail to realize is that the code is not longer or complicated at >> all. It has zero extra cost for you to read it, for me to write it, for >> the machine to execute it. >> >>> >>> And not only that, it relies on a specific VM implementation, the squeak >>> one. Presumes that the given messages are *more efficient* (just because >>> you know that the squeak compiler/vm combination makes them so). But >>> this could be wrong or at least useless in other vm (like GNU or >>> Gemstone). So by definition it is premature optimization. >> >> That's right, I don't care about other VMs. Do the developers of VW, >> Gemstone or GNU Smalltalk care about how their code will perform on >> SqueakVM or CogVM? Hardly. >> >>> >>> Lastly, to program like you (and not like others, Igor and I and most >>> people I think) we should have in the head the specifics of the vm >>> implementation and a handy list of the inlined messages of the vm. >> >> That list is surprisingly short. There are more keywords or syntax >> constructs in C/C++/Java/C#/Python/whatever than these special messages. > > The list of registers in a intel 386 cpu is short too but that doesn't > means that everyone must learn what registers are better for what kind > of datatype performance-wise. Again this is not the task for the to the messages that are inlined by the compiler? > developer. As everyone trying to do OO programing, the implementation > details are irrelevant when programming. Are you serious? > >> >>> This is the job of the JIT, not from the developer! >> >> Show me the JIT that does it. > > I said that is the *job* of the JIT not that every JIT can do it/should > do it/does it. Be honest, there's no JIT for a Pharo image, that can do this. Levente > > >> >> >> Levente >> >>> >>> >>>> - I optimize library code which is expected to be heavily used >>> >>> This the time and usage will tell >>> >>> >>>> - I like to optimize code >>> >>> Prematurely it appears! >>> >>> Cheers >>> >>> -- >>> Miguel Cobá >>> http://twitter.com/MiguelCobaMtz >>> http://miguel.leugim.com.mx >>> >>> >>> >>> >>> > > -- > Miguel Cobá > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Levente Uzonyi-2
On 13 February 2011 02:58, Levente Uzonyi <[hidden email]> wrote:
> On Sun, 13 Feb 2011, Igor Stasenko wrote: > >> Please read the Ian's paper about switch statement vs message sends.. >> You will discover something surprising for you. > > Link please? > > Here: www.piumarta.com/pepsi/objmodel.pdf- ------------------- Lastly, we implemented the example presented in Section 2 of this paper: data structures suitable for a Lisp-like language. We implemented a ‘traditional’ length primitive using a switch on an integer tag to select the appropriate implementation amongst a set of possible case labels. This was compared with an implementation in which data was stored using our object model and the length primitive used send to invoke a method in the objects themselves.7 Both were run for one million iterations on forty objects, ten each of the four types that support the length operation. The results, with varying degrees of object model optimisations enabled, were: implementation time % of switch switch-based 503 ms 100.0% dynamic object-based 722 ms 69.7% + global cache 557 ms 90.3% + inline cache 243 ms 207.0% This shows that an , object-based implementation can perform at better than half the speed of a typical C implementation for a simple language primitive. With a global method cache (constant overhead, no matter how many method invocation sites exist) the performance is within 10% of optimised C. When the inline cache was enabled the performance was better than twice that of optimised C. --------------------- > Levente > >> -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Levente Uzonyi-2
Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere. Having such strong arguments (for or against) is not helpful for anybody.
We all know using #caseOf:otherwise: it's not exactly good style, but sometimes you need to compromise between design and efficiency, and having simple and efficient constructs such as #caseOf: is very good IMHO.
You are free to avoid them if your projects don't need it, and if you happen to need extra performance you can always build your own JIT, right? :) But please don't ban people who are willing to sacrifice a little readability for performance reasons. Thanks.
Best regards. Richo 2011/2/12 Levente Uzonyi <[hidden email]>
|
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
On 13 February 2011 04:05, Ricardo Moran <[hidden email]> wrote:
> But please don't ban people who are willing to sacrifice a little > readability for performance reasons. Thanks. Then C language is your choice! It is full of such sacrifices :) But can i ask you to not turn smalltalk into C , please? > Best regards. > Richo -- Best regards, Igor Stasenko AKA sig. |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Ricardo Moran
Hi ricardo, igor and levente
I really want to remove caseOf: since years. Why: - conceptually wrong (even if this may be nice to have for $A and numbers) - to me it looks like coming from another age - never needs to use it: of course other people may of course - Three less methods in Object - only available in Squeak/Pharo - but more more more important: makes the compiler, decompiler, inliner....., more complex. I want opal to get out because we need a better infrastructure: simpler, better compiler. - Ideally I would prefer that we can extend the compiler with it and that people needed it just ship a plugin with their code. Marcus is opal dealing with caseOf:? I did not want to have a war. I thought that it was pretty obvious that we do not really need that. Stef > Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere. Having such strong arguments (for or against) is not helpful for anybody. > We all know using #caseOf:otherwise: it's not exactly good style, but sometimes you need to compromise between design and efficiency, and having simple and efficient constructs such as #caseOf: is very good IMHO. > You are free to avoid them if your projects don't need it, and if you happen to need extra performance you can always build your own JIT, right? :) > But please don't ban people who are willing to sacrifice a little readability for performance reasons. Thanks. > > Best regards. > Richo |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
Hi,
I also think we do not need caseOf: in the default distribution. It is probably useful for some cases (like dealing with integers from some external source as mentioned by Levente), but those cases are so rare that we should not affect everyone with this message. Cheers, Doru On 13 Feb 2011, at 08:57, Stéphane Ducasse wrote: > Hi ricardo, igor and levente > > I really want to remove caseOf: since years. > Why: > - conceptually wrong (even if this may be nice to have for $A and numbers) > - to me it looks like coming from another age > - never needs to use it: of course other people may of course > - Three less methods in Object > - only available in Squeak/Pharo > - but more more more important: > makes the compiler, decompiler, inliner....., more complex. > I want opal to get out because we need a better infrastructure: simpler, better compiler. > - Ideally I would prefer that we can extend the compiler with it and that people needed it just ship a plugin with > their code. > > Marcus is opal dealing with caseOf:? > > I did not want to have a war. I thought that it was pretty obvious that we do not really need that. > > Stef > >> Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere. Having such strong arguments (for or against) is not helpful for anybody. >> We all know using #caseOf:otherwise: it's not exactly good style, but sometimes you need to compromise between design and efficiency, and having simple and efficient constructs such as #caseOf: is very good IMHO. >> You are free to avoid them if your projects don't need it, and if you happen to need extra performance you can always build your own JIT, right? :) >> But please don't ban people who are willing to sacrifice a little readability for performance reasons. Thanks. >> >> Best regards. >> Richo > > -- www.tudorgirba.com "Value is always contextual." |
Re: could we agree to remove caseOf: and caseOf:otherwise:
|
|
In reply to this post by Levente Uzonyi-2
On 12 Feb 2011, at 18:41, Levente Uzonyi wrote: > ~27x slowdown in this case. I personally never heard of #caseOf:otherwise ! It feels like a hack that is not often needed. If after writing correct code you need to optimize integer/byte handling, there are many solutions, check any book on algorithms, most of them are using table dispatch. Another problem in your benchmark is that you keep the creation of the dynamic array inside the code to measure, while in the compiler primitive case it is of course compiled away, that alone makes a huge difference: (timings on my machine) [ 1 to: 10 do: [ :each | each caseOf: { [ 1 ] -> [ $a ]. [ 2 ] -> [ $b ]. [ 3 ] -> [ $c ]. [ 4 ] -> [ $d ]. [ 5 ] -> [ $e ] } otherwise: [ $x ] ] ] bench. '8,920,000 per second.' [ 1 to: 10 do: [ :each | ({ [ 1 ] -> [ $a ]. [ 2 ] -> [ $b ]. [ 3 ] -> [ $c ]. [ 4 ] -> [ $d ]. [ 5 ] -> [ $e ] } detect: [ :ea | ea key value = each ] ifNone: [ [ $x ] ]) value ] ] bench. '70,600 per second.' | actions | actions := { [ $a ]. [ $b ]. [ $c ]. [ $d ]. [ $e ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. }. [ 1 to: 10 do: [ :each | (actions at: each) value ] ] bench. '3,230,000 per second.' | letters | letters := 'abcdexxxxx'. [ 1 to: 10 do: [ :each | letters at: each ] ] bench. '8,930,000 per second.' If other Smalltalks can live without it, so can we. Sven |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |