Quantcast

could we agree to remove caseOf: and caseOf:otherwise:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
100 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

could we agree to remove caseOf: and caseOf:otherwise:

stephane ducasse
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Levente Uzonyi-2
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Levente Uzonyi-2
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.
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Levente Uzonyi-2
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.
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko
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.

>>
>> 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.

Please read the
http://www.c2.com/cgi/wiki?PrematureOptimization
:)

>
> Levente
>
>>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Levente Uzonyi-2
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.
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Miguel Cobá
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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko
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
>
Please read the Ian's paper about switch statement vs message sends..
You will discover something surprising for you.

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



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Levente Uzonyi-2
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!
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.

> 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
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Levente Uzonyi-2
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.
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Miguel Cobá
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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Levente Uzonyi-2
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
I'm sure, every assembly programmer has to learn it, but how is it related
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
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Ricardo Moran
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]>
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

I'm sure, every assembly programmer has to learn it, but how is it related 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





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Stéphane Ducasse
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Tudor Girba
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."




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: could we agree to remove caseOf: and caseOf:otherwise:

Sven Van Caekenberghe
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


12345
Loading...