Wondering about tinyBenchmarks... (was Re: [squeak-dev] Cog 2776 on Intel i7-4790K @ 4GHz)

Eliot Miranda eliot.miranda at gmail.com
Mon Sep 1 13:39:58 UTC 2014


Hi Göran,

On Sep 1, 2014, at 6:06 AM, Göran Krampe <goran at krampe.se> wrote:

> Hi guys!
> 
> While on the subject of tinyBenchmarks (toying with comparing to LuaJIT2), can someone explain a few things to me:
> 
> - Why do we take "500000 / <the-time-to-run-benchmark>" to mean bytecodes/sec? I presume its because someone made a count at some point that it takes 500000 bytecodes to find those primes? Is that still a correct estimation/presumption?

That's right.  It's probably still close.  One can count the actual number by simulating the expression using (IIRC) run:atEachStep: which is in the class side of ContextPart.

> - Why is benchFib not a correct Fibonacci sequence?

BTW Fibonacci sequences have been generalized.  See Lucas Numbers on Wikipedia.  Ffor example the classic one is close to 2^N, but one which added the previous three results would be close to 3^N, etc ("tribonacci").

But the point of benchFib is that it adds one for each and every invocation whereas the classic one adds one for each leaf activation. Hence benchFib's result is the number if activations required to evaluate it and hence dividing the result by the time in seconds taken to compute it gives a rough measure of activations per second.  This really should be in the comment.

> The implementation as it stands (seems to have been like this ever since 1998 when John Maloney (?) wrote it - I checked in a Squeak 2.5) is not a correct Fibonacci:
>   #(1 1 3 5 9 15 25 41 67 109 177)
> 
> ...while correct Fibonacci is (returning self, not 1, and not adding 1 in the recursion):
>   #(0 1 1 2 3 5 8 13 21 34 55)
> 
> It almost seems like an odd optimization gone wrong - returning 1 instead of "self" when < 2 - and then trying to compansate for the fact that "0 benchFib" should actually be 0 - by adding 1 to the result, but missing the fact that this will add 1 on every recursive call?
> 
> I presume there is something smart going on here - that makes this count "sends" better this way?
> 
> And if we just want to count sends - isn't there a better way?
> 
> Come on Bert - enlighten me! :)
> 
> Curious.
> 
> regards, Göran

Eliot (phone)


More information about the Squeak-dev mailing list