[ENH request] self class.

Andreas Raab andreas.raab at gmx.de
Sat Oct 16 03:01:56 UTC 2004


Okay, so here are some more realistic benchmarks on the bytecode #class vs. 
message #class issue:

    "find all the senders of #class"
    mrefs := SystemNavigation new allCallsOn: #class.

    "kill the byte code"
    bc := (ParseNode classPool at: #StdSelectors) removeKey: #class.
    "recompile everything"
    mrefs do:[:each| each actualClass recompile: each methodSymbol].
    "run without bytecode"
    timesNew := MacroBenchmarks run.

    "re-install bytecode"
    (ParseNode classPool at: #StdSelectors) at: #class put: bc.
    "recompile everything"
    mrefs do:[:each| each actualClass recompile: each methodSymbol].
    "run with bytecode"
    timesOld := MacroBenchmarks run.

    "Compute speed difference"
    delta := [timesNew / timesOld * 100.0]
        on: ZeroDivide do:[:ex| ex resume: ex dividend].

This results in the following (on my machine):

MB1: 101.83 (compile, decompile, pretty print)
MB2: 101.31 (build morphic tiles for large methods)
MB3: 102.28 (translate interpreter with inlining)
MB4: 103.57 (run context step simulator)
MB5: n/a    (not run)
MB6: 104.99 (open ten browsers)
MB7: 98.61  (play a game of freecell)

So it looks like the worst we ever get is a loss of 5% which is (admittedly) 
more than I expected though it's hard to say what the confidence interval is 
(in particular considering MB7 - being faster than without the bytecode is 
plain impossible so some other factors on this machine have to be taken into 
account). I'd like to see other people send their numbers.

BTW, loosing one percent in speed may not sound much but we *have* changed 
the VM for an effective +1% in speed. They're simple to loose those percent 
and hard to gain.

Cheers,
  - Andreas

----- Original Message ----- 
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, October 15, 2004 6:30 PM
Subject: Re: [ENH request] self class.


>> If the importance of "Object class" execution time relative to
>> timesRepeat: code is so low (10% loss in execution time) in the example,
>> then isn't it going to be even less significant in real code?
>
> That is quite likely - I would expect the actual effect to be neglectable 
> (as in < 0.1%). You see - the claim that "it's around 10% slower" is 
> ridiculous on both ends. From the micro point of view we have benchmarks 
> that show that there is a difference of ~10x between message send and byte 
> code (btw the "benchmark" below strikes me as one that can only be seen as 
> a micro) so the result is out of the ordinary by two orders of magnitude. 
> For a macro I wouldn't expect to see a loop like the one below and so 
> again I'd say this is probably wrong by two orders of magnitude.
>
> Whatever it is that is being presented with this "benchmark" I wouldn't 
> use it to discuss whether there is a speed difference between the message 
> #class and the class bytecode.
>
> Cheers,
>  - Andreas
>
> ----- Original Message ----- 
> From: "Samuel Tardieu" <sam at rfc1149.net>
> To: <squeak-dev at lists.squeakfoundation.org>
> Sent: Friday, October 15, 2004 6:12 PM
> Subject: Re: [ENH request] self class.
>
>
>>>>>>> "Andreas" == Andreas Raab <andreas.raab at gmx.de> writes:
>>
>> Andreas> Marcus, I'm surprised to see you making such outrageous and
>> Andreas> ridiculous claims:
>>
>>>> [1000000 timesRepeat: [Object class]] timeToRun
>>>>
>>>> With special bytecode: 514 Without: 579
>>>>
>>>> So it's around 10% slower.
>>
>> Andreas> More likely (given our micro benchmarks) the difference is a
>> Andreas> factor of ten (message send vs. byte code).
>>
>> If the importance of "Object class" execution time relative to
>> timesRepeat: code is so low (10% loss in execution time) in the example,
>> then isn't it going to be even less significant in real code?
>>
>>  Sam
>> -- 
>> Samuel Tardieu -- sam at rfc1149.net -- http://www.rfc1149.net/sam
>>
>>
>>
>
>
> 




More information about the Squeak-dev mailing list