Hi Andreas,

on Sun, 17 Dec 2006 13:51:53 +0100, you wrote:
> Klaus D. Witzel wrote:
>> O.K. I understand that as lack of use case. Take this (take that ;-)
>>   | allCs |
>>  allCs := Smalltalk allClasses.
>>  "start timing here"
>>  1 to: allCs size do: [:i | (allCs at: i) methodDict "just access the  
>> iVar"]
>>  "note that #yourself from the previous example is now just #methodDict"
>>  This snippet is performed on behalf of every developer who asks for  
>> senders and/or implementors. It is, IMHO, the most often used piece of  
>> code of every Smalltalk, ever.
>
> Absolutely not. Your claim that "this snippet is performed on behalf of  
> every developer who asks for senders and/or implementors" is misleading.  
> This is not what is *actually* performed.

Of course it is performed, even in reality.

> What is actually done is a lot more.

That's you point, accepted, agreed, out (and what about over ;-)

> For every single mega-morphic send you have dozens of mono-morphic sends.
>
> That is my whole point.

Agreed, NP.

> Just like in your previous post, you are not using actual code

The previous post has a simulation of actual code, I have no doubts (see  
also my layers thing below, which I hope explains).

> but rather a specifically devised micro-benchmark that has none of the  
> characteristics of actual code.

Sending #methodDict to a collection instances of behavior IS reality,  
sorry. Perhaps you meant something else?

> It's not done sending #methodDict - this is when the work starts not  
> when it ends.

But this is "only" your point. My point is, performance is performance.  
The possible dozens of mono-morphic sends do not amorthisize the bad (in  
my case) mini-morphic performance.

I agree they could've been responsible for amorthisation of the investment  
if the figures where true for ">=" but, the latter is apparently not the  
case.

Hey man, I understand you point. But a PIC of size 8 is not a mega-morphic  
thing. Let's not take this one any further (if possible, please).

> If you look at the actual code that is executed, say:
>
>      MessageTally tallySends:[Time browseAllCallsOn: #yourself]
>
> you will find that when browsing senders there are some 50 messages sent  
>   in addition to the single mega-morphic send and it is *those* fifty  
> messages are where the real work is - the single mega-morphic send is  
> simply noise in the overall performance.

Well, I used #yourself because a) I was not interested in any particular  
implementation, which b) has constant response time and c) because it is  
guaranteed to not choke the test. I was not interested in the leafs, right  
you are.

In my imagination a system like Smalltalk has several layers. And I timed  
just one of them and found the results.

> And it's these fifty messages (which have different performance  
> characteristics) where Strongtalk just completely rulez.
>
>> But, even for the latter I expect to find the = in >= when Strongtalk  
>> "...executes Smalltalk much faster than any other Smalltalk  
>> implementation...".
>
> The claim is about "Smalltalk code", not about "Klaus Witzel Benchmarks"  
> (the difference between the two should be obvious).

Not that I see any difference, I posted Smalltalk code (perhaps you meant  
something else?)

> I can always design you a benchmark that makes a particular system look  
> bad.

C'mon. It's either faster or it's not. No way out.

>>> I would expect that you know how to evaluate the results of a  
>>> micro-benchmarks, and I would in particular expect that you know that  
>>> 80-90% of all call-sites in realistic code are mono-morphic to begin  
>>> with which render your benchmark results absolutely useless for  
>>> "Smalltalk code".
>>  Absolutely not (yes, I know about these figures. no, I disagree: see  
>> above).
>
> If you know about the figures, then how can you claim that your  
> benchmark has any validity for general code?

Did I? I see this rather as a counter example which sheds some light on  
the performance claim (using your words, sheds some "Klaus Witzel code"  
light ;-)

And I found some system whose performance didn't pass a simple Thue-Morse  
sequence test :-)

> And as I am saying in the above the *actual* code has "Smalltalk  
> performance characteristics" whereas your made-up micro-benchmark  
> doesn't.

C'mon. Sending messages to elements of collections _is_ characteristic for  
the Smalltalks.

/Klaus

> Cheers,
>    - Andreas
>
>