[squeak-dev] Re: Re: squeak performance
Alain_Rastoul
alr.dev at free.fr
Sat May 22 00:26:10 UTC 2010
Hi Eliot,
You are right, the benchmark is too simple to be significant, and as you suggested I increased the value of n and got more stable results between runs and less impact of the Squeak process priority.
Just to mention it, the ratio of 98% I'm talking about is a cache hit ratio (#cache hits / #total finds) in Interpreter that
I count in internalFindNewMethod, resetting counters after getting them in vmParameterAt:.
It keeps the same values whatever the result of the test is (good or bad) which is a good point,
and it gets better values with n greater (99.8 % with 32 benchFib).
Thanks Eliot, I'll keep that in mind for next benchmark trials :-)
regards,
Alain
"Eliot Miranda" <eliot.miranda at gmail.com> a écrit dans le message de news: AANLkTikQXaGTUdBdau0Ua36p7Mo3gXMVFvV-aUA58-rp at mail.gmail.com...
Hi Alain,
I think what you're seeing here is clock resolution. I think you're running too simple a benchmark to get reliable results. When I run on Cog (2.66GHz Intel Core i7) I get most results around 65,000,000, the occasional one around 50,000,000 and rarely one around 98,000,000. But when I try evaluating 30 benchFib instead of 26 benchFib things settle down. When I use 32 benchFib (which takes around 125 ms) I see very small variance, every result being between 55,000,000 and 58,000,000. SI experiment with different values and see if your times settle down as you increase N also.
On Fri, May 21, 2010 at 2:37 PM, Alain_Rastoul <alr.dev at free.fr> wrote:
Right, it has nothing to do with commonSend and cache.
Being stubborn I added cache hit / misses counters to the vm but it showed
nothing significant except a very good ratio : 95 to 98% :)
In addition, putting the squeak process to a lowest priority (even "idle")
seems to make it run much faster (!!!).
Strange Windows.
Regards
Alain
"Levente Uzonyi" <leves at elte.hu> a écrit dans le message de news:
Pine.LNX.4.64.1005211945090.15643 at login01.caesar.elte.hu...
> On Fri, 21 May 2010, Alain_Rastoul wrote:
>
>> Hello,
>>
>> I recently tryed then 4.1 and discovered a strange behavior that
>> appearead
>> to be true with the 3.10 also.
>> The test is simply running benchFib in series of runs.
>> If I run the test 10 times, on of the run is about 2-3 times faster than
>> the
>> others, and I can't explain that.
>>
>> 10 timesRepeat: [
>> | r t |
>> t := Time millisecondsToRun: [r := 26 benchFib].
>> Transcript show: ((r * 1000) // t) ; cr.
>> ]
>
> I can't reproduce this. I think it's just noise from your OS. But try to
> evaluate this:
>
> [
> ((1 to: 100)
> collect: [ :run |
> (Integer >> #benchFib) flushCache.
> [ 26 benchFib ] timeToRunWithoutGC ]) sort ] valueAt: 80.
>
> If you get the same results, then GC and caching doesn't change the
> behavior, so you can be pretty sure that it's just OS-noise. Try
> increasing the priority of Squeak's process and repeat the tests.
>
>
> Levente
>
>>
>> will give me 10 numbers about 2486297 (one of the runs)
>> but one run will give me 10 numbers about 6773017.
>> I stopped all I could stop on my laptop and nothing else but squeak is
>> running...
>> I made a TimeProfileBrowser and the inner loop of the profile seems to
>> show
>> that primitives are more than 2 times faster.
>> (and everything seems 2 times faster)
>> Anybody noticed that (I searched the web but found nothing) ?
>> primitive calls ?
>> methodCache?
>>
>>
>> Best regards,
>>
>> Alain
>>
>>
>>
>>
>>
>
>
------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100522/bd1523f5/attachment.htm
More information about the Squeak-dev
mailing list
|