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

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Alexandre Bergel

>>> Counting messages is, in the average, closely link to the average execution time. > In the setting of the paper, that might be correct. > Even for the stated goal of optimizing for performance, it might still be interesting. > However, the optimizations done based on this criteria are bound to one specific VM implementation. Not only to the VM, but also to the compiler. >> I believe this is correct only as long as a purely interpreting VM is >> used, even though quick messages add a tiny bit of uncertainty. But >> add a JIT compiler and some inlining, and timeToRun and MessageTally >> are suddenly interesting again. > Or have a VM that is not Squeak, and perhaps use a language that is not used in the style Smalltalk is (7 lines of code per method, right?). Yes, but there hasn't been a major change on the VM front since I started Smalltalk. Cog is the notable exception, but the assumption I made without Cog remains valid with Cog. > Have only skimmed the paper, Alexandre, so excuse the perhaps stupid question: Why don't you just count the number of executed bytecodes? The correlation between bytecodes and execution time should be even more close than messages to exec time. Indeed, it does. Counting bytecode instructions is also a valid way to estimate average execution time. There is some work on this (cf the related work section). Counting bytecode is more expensive than counting messages. In general, my opinion is that OO programming is about sending messages, not executing bytecode. Message counting has also the advantage to be friendlier with a JIT. > Bye the way, the remark on the mismatch between OO programming and profiling: profiling is about the execution model, and the execution model of Smalltalk is based on a stack machine. To me the execution model seems to be orthogonal to the structuring of the code. I don't see how you can really abstract from that, without coming up with a 'object-oriented' execution model (what ever that would be). Perhaps, the closest to that would be an actor-based execution model, like Erlang's language semantics. No stacks just message buffers. Most profilers, including MessageTally, count stack frames at a regular interval. This is doomed to be inexact, non-deterministic and non-portable, and so, whatever the effort you will put in the thread scheduling, memory management or whatsoever. I am simply focusing on sending messages, which is in my opinion, the essence of the OO executing model. Using a stack machine is an implementation matter. It is not essential to OO. Alexandre > > > Best regards > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Michael Haupt

Hi Alex, On 28 April 2011 18:14, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Or have a VM that is not Squeak, and perhaps use a language that is not used in the style Smalltalk is (7 lines of code per method, right?). > > Yes, but there hasn't been a major change on the VM front since I started Smalltalk. Cog is the notable exception, but the assumption I made without Cog remains valid with Cog. do you mean "on the *Smalltalk* VM front"? I'm pretty sure you do. :-) > Most profilers, including MessageTally, count stack frames at a regular interval. This is doomed to be inexact, non-deterministic and non-portable, and so, whatever the effort you will put in the thread scheduling, memory management or whatsoever. I think you're being a bit harsh on stack sampling there. It is exact enough to drive optimisation in some really high-performance VMs. It is also deterministic enough to yield data leading to very good performance results in those VMs. Whether focusing on counting messages instead of taking samples is more beneficial would have to be determined by experiment ... What you mean with "non-portable" I do not understand. > I am simply focusing on sending messages, which is in my opinion, the essence of the OO executing model. Yup, good point. Best, Michael

April 28, 2011

Re: [Pharo-project] squeaksource is down - a different perspective

by Dale Henrichs

Haha, .... now I see that:) On Apr 27, 2011, at 11:13 PM, StÃ©phane Ducasse wrote: > I was thinking about migration from SS to SS3 > On Apr 27, 2011, at 10:16 PM, Dale Henrichs wrote: > >> Since you mention GemStone:) >> >> We have customers who have migrated repositories created 10+ years ago with our 32 bit product to the latest current version of our 64 bit product. >> >> We have changed our Smalltalk class-library over the years and customers have had to upgrade their own class libraries if they chose to continue taking advantage of our newer releases ... then there are some who have chosen not to migrate: I think there are still production applications running GemStone on a version 20 years old:) ... as long as their hardware holds out they are fine:) >> >> Production customers don't tend to move very fast in upgrading their hardware and software so we end up supporting older versions of oSes for quite awhile...But when the os vendor announces and end of life of an os, it becomes difficult for us to continue to support that version... >> >> For the older versions we backport critical bugfixes to the older versions as long as their are active customers (read paying maintenance dollars) using the older versions. >> >> Dale >> >> >> On 04/27/2011 10:23 AM, StÃ©phane Ducasse wrote: >>> >>>>> squeaksource.com is down a lot. People get frustrated at times. >>>> >>>> Yes, and unfortunately it looks like people love to be frustrated. >>>> >>>> Otherwise people would give Tobias more feedback on SqueakSource3 (see [1]) which IMHO could overtake the job in the future and replace the >>>> problematic image? >>> >>> I do not know. >>> Do SS3 has a migration process? >>> How easy is it to install on an old machine? >>> Does gemstone run on a old mac g3? >>> Should we install glass? >>> I do not know. >>> >>> You see nothing looks simple when we want to do it. >>> >>>> Or is the outage a traffic problem and may >>>> happen with SS3 too? >>>> >>>> Is the (daily?) restart the only option we have or is a migration >>>> to a newer SS version possible? >>> >>> No idea. >>> Do you know? >>> >>>> And yes - SmalltalkHub is on the way, but we still dont know >>>> how well it fits our needs/works/scales. Yes, this sounds negative but >>>> I think it can replace Squeaksource only in a long term... >>> >>> we will see and learn. >>> >>>> Bye >>>> T. >>>> >>>> >>>> [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-April/047780.html >>>> -- >>>> NEU: FreePhone - kostenlos mobil telefonieren und surfen! >>>> Jetzt informieren: http://www.gmx.net/de/go/freephone >>>> >>> >>> >> >

April 28, 2011

Re: [Pharo-project] [smalltalk-research] Re: Counting Messages as a Proxy for Average Execution Time in Pharo

by Alexandre Bergel

>> I agree with you that the result I found may not be valid in Java or .Net. However they are for the current Pharo. And apparently, this is not likely to change anything soon. > > Not even with increasing support from Cog? No idea. Together with Eliot we implemented Compteur in Cog. I made some experiments and the results are apparently similar than in a non-jitted VM. If Cog continue to improve, then the assumptions may not be valid anymore. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Alexandre Bergel

Hi Michael, There is a long discussion in the paper about exactly what you are mentioning here. The assumptions are made for the current version of Pharo: with its naive VM, not state-of-the-Art JIT, naive compiler, simple GC and so on. I agree with you that the result I found may not be valid in Java or .Net. However they are for the current Pharo. And apparently, this is not likely to change anything soon. Alexandre On 28 Apr 2011, at 08:57, Michael Haupt wrote: > Alex, > > On 28 April 2011 15:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Counting messages is, in the average, closely link to the average execution time. > > I believe this is correct only as long as a purely interpreting VM is > used, even though quick messages add a tiny bit of uncertainty. But > add a JIT compiler and some inlining, and timeToRun and MessageTally > are suddenly interesting again. > > Not having read your text, I surely cannot say anything remotely > conclusive, but the assumption that execution time roughly equals the > amount of messages sent seems rather naÃ¯ve once you leave the cosy > well-predictable niche inhabited by pure interpreters. > > Best, > > Michael > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2011

[Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Alexandre Bergel

Hi! There has been many discussion on profiling and execution. I believe the paper titled "Counting Messages as a Proxy for Average Execution Time in Pharo" draws some bases for a new generation of code profilers that are not tied to execution sampling. Advantages are numerous without not that many drawbacks. http://bergel.eu/download/papers/Berg11c-compteur.pdf I will put some effort on having "Compteur" in the main Pharo vm. This has to be carefully done and monitored to make sure there is no unwanted overhead. In the experience I have done, there is no overhead. I have started to get in touch with people close to the VM. I will keep you informed, especially when reviews and testing will be needed. One very cool think that everybody can benefit from, is to be able to write assertion in unit tests like: self assertIs: [ "expression1" ] fasterThan: [ "expression2" ] It compares the amount of messages sent by expression1 with the amount of messages sent by expression2, no matter how many messages are sent. Counting messages is, in the average, closely link to the average execution time. This cannot be done with [ ... ] timeToRun or MessageTally. I will keep you informed. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Stefan Marr

Hi: On 28 Apr 2011, at 16:08, Alexandre Bergel wrote: >>> I agree with you that the result I found may not be valid in Java or .Net. However they are for the current Pharo. And apparently, this is not likely to change anything soon. >> >> Not even with increasing support from Cog? > > No idea. Together with Eliot we implemented Compteur in Cog. I made some experiments and the results are apparently similar than in a non-jitted VM. > > If Cog continue to improve, then the assumptions may not be valid anymore. As soon as the VM does aggressive method inlining your message sends disappear and you can't count them anymore. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Stefan Marr

Hi: On 28 Apr 2011, at 14:57, Michael Haupt wrote: > On 28 April 2011 15:37, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Counting messages is, in the average, closely link to the average execution time. In the setting of the paper, that might be correct. Even for the stated goal of optimizing for performance, it might still be interesting. However, the optimizations done based on this criteria are bound to one specific VM implementation. > I believe this is correct only as long as a purely interpreting VM is > used, even though quick messages add a tiny bit of uncertainty. But > add a JIT compiler and some inlining, and timeToRun and MessageTally > are suddenly interesting again. Or have a VM that is not Squeak, and perhaps use a language that is not used in the style Smalltalk is (7 lines of code per method, right?). Have only skimmed the paper, Alexandre, so excuse the perhaps stupid question: Why don't you just count the number of executed bytecodes? The correlation between bytecodes and execution time should be even more close than messages to exec time. Bye the way, the remark on the mismatch between OO programming and profiling: profiling is about the execution model, and the execution model of Smalltalk is based on a stack machine. To me the execution model seems to be orthogonal to the structuring of the code. I don't see how you can really abstract from that, without coming up with a 'object-oriented' execution model (what ever that would be). Perhaps, the closest to that would be an actor-based execution model, like Erlang's language semantics. No stacks just message buffers. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 28, 2011

Re: [Pharo-project] [smalltalk-research] Re: Counting Messages as a Proxy for Average Execution Time in Pharo

by Michael Haupt

Hi Alex, On 28 April 2011 16:03, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > There is a long discussion in the paper about exactly what you are mentioning here. wonderful, I'm going to go read it then. :-) > I agree with you that the result I found may not be valid in Java or .Net. However they are for the current Pharo. And apparently, this is not likely to change anything soon. Not even with increasing support from Cog? Best, Michael

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by Alexandre Bergel

Hi Jannik, > === > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > str := WriteStream on: (String new). > 9000 timesRepeat: [ str nextPut: $A ]]]. > === > > The result appears after 812 ms, which is a large improvement. > Now, we could optimize again using the preallocation. Here is my source code: > > ==== > MessageTally spyOn: > [ 500 timesRepeat: [ > | str | > str := WriteStream on: (String new: 10000). > 9000 timesRepeat: [ str nextPutAll: 'A' ]]]. > ==== In the first case you use nextPut:, in the second case you use nextPutAll:. Replacing nextPutAll: by nextPut: gives me coherent result. 330 ms for the first, and 321 for the second (with the preallocation). Alexandre > And the result is strange: it makes 2 times slower to display the result. > The result appears after 1656 ms. > > Here is the spy result: > === > - 1656 tallies, 1656 msec. > > **Tree** > -------------------------------- > Process: (40s) 464519168: nil > -------------------------------- > **Leaves** > 22.9% {380ms} UndefinedObject>>DoIt > 22.5% {373ms} SmallInteger(Integer)>>timesRepeat: > 22.2% {368ms} WriteStream>>nextPutAll: > === > > There is the call of UndefinedObject>>DoIt which is added and takes time. > Does anyone know what is done during the preallocation ? > Why is it slower than non-preallocation ? > > Thanks for your answers. > Jannik -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2011