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

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

by Alexandre Bergel

>> 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 ... Yes, 25 pages of experiment :-) > What you mean with "non-portable" I do not understand. The information about the execution time contained in your profile cannot be compared with a new profile realized on a different machine, with a different CPU. 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 Nicolas Cellier

2011/4/29 Alexandre Bergel <alexandre.bergel(a)me.com>: >> One silly idea while reading this thread (not the paper): >> For single core, the idea makes sense. >> It may even extend easily to multicore VM (just forget about Smalltalk >> for a while) by counting message sent per core and taking the max. > > But you are here assuming that all the CPU have the same speed (#messages/sec) right? > > Alexandre > Sure, an obvious limitation... >> >> Nicolas >> >> 2011/4/29 Alexandre Bergel <alexandre.bergel(a)me.com>: >>> +1 >>> >>> Alexandre >>> >>> >>> On 28 Apr 2011, at 17:35, Michael Haupt wrote: >>> >>>> Hi Alex, >>>> >>>> On 29 April 2011 00:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>>> 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 ... >>>>> >>>>> Yes, 25 pages of experiment :-) >>>> >>>> oh, I was not referring to your paper. I was referring to the general >>>> applicability of message counting as opposed to sampling. The latter >>>> is true-and-tried in many high performance VMs. For the former, an >>>> experiment has yielded good results (from what I take from this thread >>>> - I still haven't read your paper, sorry, it's on top of the pile) in >>>> a constrained setting. All I was saying is that it is not possible to >>>> conclude anything for the broader area from the experiments you >>>> conducted. But we're probably of the same opinion here. >>>> >>>>>> What you mean with "non-portable" I do not understand. >>>>> >>>>> The information about the execution time contained in your profile cannot be compared with a new profile realized on a different machine, with a different CPU. >>>> >>>> That is correct, but the approach itself is portable - may I quote >>>> you: "Most profilers, including MessageTally, count stack frames at a >>>> regular interval. This is doomed to be inexact, non-deterministic and >>>> non-portable". You weren't talking about the results. Those are >>>> obviously specific to the platform, clock frequency, L1/L2/L3 cache >>>> and memory sizes, application input (!) and other factors. >>>> >>>> Best, >>>> >>>> Michael >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel Â http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

April 28, 2011

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

by Nicolas Cellier

One silly idea while reading this thread (not the paper): For single core, the idea makes sense. It may even extend easily to multicore VM (just forget about Smalltalk for a while) by counting message sent per core and taking the max. Nicolas 2011/4/29 Alexandre Bergel <alexandre.bergel(a)me.com>: > +1 > > Alexandre > > > On 28 Apr 2011, at 17:35, Michael Haupt wrote: > >> Hi Alex, >> >> On 29 April 2011 00:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> 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 ... >>> >>> Yes, 25 pages of experiment :-) >> >> oh, I was not referring to your paper. I was referring to the general >> applicability of message counting as opposed to sampling. The latter >> is true-and-tried in many high performance VMs. For the former, an >> experiment has yielded good results (from what I take from this thread >> - I still haven't read your paper, sorry, it's on top of the pile) in >> a constrained setting. All I was saying is that it is not possible to >> conclude anything for the broader area from the experiments you >> conducted. But we're probably of the same opinion here. >> >>>> What you mean with "non-portable" I do not understand. >>> >>> The information about the execution time contained in your profile cannot be compared with a new profile realized on a different machine, with a different CPU. >> >> That is correct, but the approach itself is portable - may I quote >> you: "Most profilers, including MessageTally, count stack frames at a >> regular interval. This is doomed to be inexact, non-deterministic and >> non-portable". You weren't talking about the results. Those are >> obviously specific to the platform, clock frequency, L1/L2/L3 cache >> and memory sizes, application input (!) and other factors. >> >> Best, >> >> Michael >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 29 April 2011 00:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> 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 ... > > Yes, 25 pages of experiment :-) oh, I was not referring to your paper. I was referring to the general applicability of message counting as opposed to sampling. The latter is true-and-tried in many high performance VMs. For the former, an experiment has yielded good results (from what I take from this thread - I still haven't read your paper, sorry, it's on top of the pile) in a constrained setting. All I was saying is that it is not possible to conclude anything for the broader area from the experiments you conducted. But we're probably of the same opinion here. >> What you mean with "non-portable" I do not understand. > > The information about the execution time contained in your profile cannot be compared with a new profile realized on a different machine, with a different CPU. That is correct, but the approach itself is portable - may I quote you: "Most profilers, including MessageTally, count stack frames at a regular interval. This is doomed to be inexact, non-deterministic and non-portable". You weren't talking about the results. Those are obviously specific to the platform, clock frequency, L1/L2/L3 cache and memory sizes, application input (!) and other factors. Best, Michael

April 28, 2011

Re: [Pharo-project] [TODO] 1.2.2

by Marcus Denker

On Apr 28, 2011, at 10:50 PM, laurent laffont wrote: > - Is it possible to revert to last successful build ? > It just started failing with no change done. (phase of the moon...) > - Seems related to OB, but I see http://code.google.com/p/pharo/issues/detail?id=3842 , so I suppose Hudson scripts should be updated but few people have access ? > possibly related. It was fixed for 1.3, but not 1.2 > - Indeed OB maintenance process looks really problematic > We need *one* browser. Maintaining two makes no sense. > - Which mailing-list the mail is sent ? Haven't seen it on pharo-dev (but inbox full of mails ahhhhhhh) > this one. > Laurent > > > On Thu, Apr 28, 2011 at 9:17 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Core: > > Failing Tests: NONE > Open Issues: NONE > > Full: > > - Issues: 4. Related to OB: 3 OB2: 1. http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2.2-DevImage > - the build of Full is broken since April, 14th (2 weeks). > A Mail is sent automatically on each failiing build (minimum 1/day) > Result: No action. > > Most important next step: > - Fix Build of Full. > > I really woner why we have the Full image... > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 28, 2011

Re: [Pharo-project] [TODO] 1.2.2

by laurent laffont

- Is it possible to revert to last successful build ? - Seems related to OB, but I see http://code.google.com/p/pharo/issues/detail?id=3842 , so I suppose Hudson scripts should be updated but few people have access ? - Indeed OB maintenance process looks really problematic - Which mailing-list the mail is sent ? Haven't seen it on pharo-dev (but inbox full of mails ahhhhhhh) Laurent On Thu, Apr 28, 2011 at 9:17 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > Core: > > Failing Tests: NONE > Open Issues: NONE > > Full: > > - Issues: 4. Related to OB: 3 OB2: 1. > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2.2-DevImage > - the build of Full is broken since April, 14th (2 weeks). > A Mail is sent automatically on each failiing build (minimum > 1/day) > Result: No action. > > Most important next step: > - Fix Build of Full. > > I really woner why we have the Full image... > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

April 28, 2011

Re: [Pharo-project] [TODO] 1.2.2

by StÃ©phane Ducasse

>> > We need *one* browser. Maintaining two makes no sense. yes but saying it will not make it happen. Benjamin worked hard and this is promising. I'm working on rpackage to make sure we can get nautilus but this is not trivial. And the more I program the more I'm convinced that we should not be compatible with MC subpackage semantics. stef

April 28, 2011

Re: [Pharo-project] [TODO] 1.3

by Alain Plantec

of course, no problem :) btw: I like the current Transcript window, I would let it readonly ... Cheers Alain Le 28/04/2011 20:56, StÃ©phane Ducasse a Ã©crit : > no stress guys. > take the time and give time. > there are plenty of other stuffs to do and at the end we can revert so this is quite cool > The risk is low. This is not like: ok fix the %^&*( code management system because there no backup. > So we should be nice and welcoming the energy that fernando is putting to improve the system. > if at the end the results is not at the right level: I take 2 hours and fix everything but > we should welcome hiccups in progress and let people put their energy on the table without having to do > right perfect the first time. > > Stef >

April 28, 2011

Re: [Pharo-project] [TODO] 1.3

by Alain Plantec

Le 28/04/2011 21:21, Marcus Denker a Ã©crit : > Core > Failing Tests: NONE > Open Issues: 23 http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 > Related to Transcript: 8 > > Full > Failing Tests: 37. Related to Nile: 30. https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/lastCompletedBuild/t… > Open Issues: 9. http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3-DevImage > > Next most important Step: > -> fix Transcript. what about revert the Transcript and push the new one again in 1.4 ? Cheers Alain > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

April 28, 2011

Re: [Pharo-project] UndefinedObject(Object)>>doesNotUnderstand: #findNextHandlerContextStarting

by Toon Verwaest

> On Wed, Apr 27, 2011 at 11:31 AM, Marcus Denker > <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > On Apr 24, 2011, at 5:12 PM, Mariano Martinez Peck wrote: > > > grrrr I don't know what is happening. I am building a PharoDev > 1.3 and at the end, I do: Undeclared removeUnreferencedKeys > > but this throws an error that I attach. It is a big loop of such > error. > > The progress bar is showing "Clean up in DebuggerMethodMap" > > > > So I added the DebuggerMethodMap intialize (reset the cache) to > Smalltalk cleanUp. > > But why is that called when calling "Undeclared > removeUnreferencedKeys"? > > > Because the DebuggerMethodMap holds onto older versions of methods > and these can be sources of undeclared references. > If DebuggerMethodMap's collection of methods is properly weak then > this isn't an issue but in practice this belt-and-braces approach is > more robust. Is there a good reason why the debugger method map stores this data? It seems horribly complex for not that much gain ... When I started working on the Glamour Debugger I reimplemented the debugger method map as the GTDebugMethodModel which is a hyper-simplification of the DebuggerMethodMap for a big part since I don't have to handle caching. ... and honestly, I never noticed any slowdown in the debugger. Of course it could just be that my machine is too fast... or that it's used somewhere else; or that my code just wasn't complete or so. cheers, Toon

April 28, 2011