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

Alexandre Bergel alexandre.bergel at me.com
Fri Apr 29 16:22:56 CEST 2011


I am not sure to which paper you are referring to. But yes, I read the one that we mentioned in the various emails.
"Wake Up and Smell the Coffee" is a good one. 

Actually, there are several papers on a similar topic. The ones that I like very very much are:
  - "Producing wrong data without doing anything obviously wrong!" 
  - "Evaluating the accuracy of java profilers."

The authors of these papers are Todd Mytkowicz, Amer Diwan, Matthias Hauswirth, and Peter F. Sweeney. These guys really rock. They will be at ecoop.

Cheers,
Alexandre


On 29 Apr 2011, at 04:32, Stéphane Ducasse wrote:

> alex did you read the OOPSLA paper stefan or michael sent around about profiling and the default flaw in research approach?
> 
> Stef
> 
> On Apr 29, 2011, at 12:40 AM, Alexandre Bergel wrote:
> 
>> +1 
>> 
>> Alexandre
>> 
>> 
>> On 28 Apr 2011, at 17:35, Michael Haupt wrote:
>> 
>>> Hi Alex,
>>> 
>>> On 29 April 2011 00:08, Alexandre Bergel <alexandre.bergel at 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.








More information about the Pharo-project mailing list