February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 13 February 2011 02:58, Levente Uzonyi <leves(a)elte.hu> 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.

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Levente Uzonyi

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

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Miguel CobÃ¡

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

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Levente Uzonyi

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

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Levente Uzonyi

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

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 13 February 2011 02:26, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sun, 13 Feb 2011, Igor Stasenko wrote: > >> On 13 February 2011 00:59, Levente Uzonyi <leves(a)elte.hu> 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.

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by 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

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Levente Uzonyi

On Sun, 13 Feb 2011, Igor Stasenko wrote: > On 13 February 2011 00:59, Levente Uzonyi <leves(a)elte.hu> 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. > >

Feb. 13, 2011

Re: [Pharo-project] [Hudson] Cog Unix build

by Miguel CobÃ¡

Markus, Igor, everyone, this is *excellent work*. It is really a tremendous leap forward. It is amazing how the different efforts (hudson, configuration, modern handling of VM sources, Cog VM, Pharo Core) of the community can converge to something as useful as we see here. Thanks to everyone involved in this step by step (as Stef says) continuous daily effort. The fruits are growing in the Pharo project tree! El sÃ¡b, 12-02-2011 a las 23:19 +0100, Igor Stasenko escribiÃ³: > On 12 February 2011 18:38, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hudson news > > ------------------ > > > > Cog Unix > > > > https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/ > > > > This is using Igor's non-interactive build. Hudson does the following: > > > > git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git > > cd sig-cog/codegen-scripts > > sh ./buildImage.sh -nodisplay > > sh ./generate.sh -nodisplay ./CogUnix.st > > i changed the generate.sh to take the configuration class name. > > So now we should have multiple (sub)projects for building VM for each > of the following configurations: > > sh ./generate.sh -headless CogUnixConfig > sh ./generate.sh -headless StackInterpreterUnixConfig > sh ./generate.sh -headless StackInterpreterDebugUnixConfig > sh ./generate.sh -headless CogDebugUnixConfig > > > cd sig-cog/build > > cmake . > > make > > zip -r Cog.zip results/* > > > > Problems: > > - do not do a clone but update the checked out source when they are already there > > - the generated VM crashes shortly after image startup > > > > But nevertheless, another tiny step. > > > > Yes. i found the issue. Now it runs!!! :) > > And i were able to run all tests in pharo 1.3 core image on StackVM: > > 7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 > unexpected passes > > no more crashes! :) > > > > What is nice is that this allows to trigger a build (and test) automatically when either > > a new monticello or git commit happens, leading to a much faster turnaround when > > doing changes to the VM. > > > > Ideally, build should be triggered only when we commit something to git :) > > I should fix the codegen-scripts/LoadVMMaker.st to always use exact > package version(s) for building image, > not the latest one. > So, then by checking-out some historical commit, one should be able to > reproduce the same VM as we had, > when committing it. > > And for testing if VMMaker could be loaded into latest development > image, we can set up a separate project or use different scripts. > > > > And of course the other important reason is that this allows people to set up their > > own auto-build from a git clone when doing VM experiments, very useful in a > > research and university setting. > > > > > > Marcus > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Feb. 13, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 13 February 2011 00:59, Levente Uzonyi <leves(a)elte.hu> 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.

Feb. 13, 2011