- Pharo-dev - lists.pharo.org

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

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

by Michael Haupt

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

April 28, 2011

Re: [Pharo-project] XML and DTD

by StÃ©phane Ducasse

On Apr 28, 2011, at 11:58 AM, Olivier Auverlot wrote: > Hi, > > Now, I'm playing with XML-Parser. It's a funny game but I have a little question. How to validate a XML file with a DTD ? I do not know. In VisualWorks there was a kind of validator now in XMLwriter....package I do not know. > > Thank for your help. > > Best regards > Olivier ;-) > > www.auverlot.fr >

April 28, 2011

[Pharo-project] Smalltalk position in Germany

by stephane ducasse

Hi guys HRWorks is looking for a good smalltalker (with potentially some german knowledge). If you are interested contact Thomas Holzer <thomas.holzer(a)hrworks.de> Stef

April 28, 2011

Re: [Pharo-project] Preallocation behavior

by jannik.laval

Hi all, thank you for the information. In fact, Alex you are right, I have a nextPutAll: that I should replace. Cheers, Jannik On Apr 28, 2011, at 15:02 , Alexandre Bergel wrote: > 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