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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Apr 29 00:03:04 CEST 2011


2011/4/29 Alexandre Bergel <alexandre.bergel at 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 at 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 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