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

Stéphane Ducasse stephane.ducasse at inria.fr
Fri Apr 29 10:32:10 CEST 2011


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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 
> 
> 




More information about the Pharo-project mailing list