<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18904">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Hi Eliot,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV>
<DIV><FONT size=2 face=Arial>You are right, the benchmark is too simple to
be significant, and a</FONT><FONT size=2 face=Arial>s you suggested I increased
the value of n and got more stable results between runs and less
impact of the Squeak process priority.</FONT></DIV></DIV><FONT size=2
face=Arial>
<DIV> </DIV>
<DIV>Just to mention it, the ratio of 98% I'm talking about is a cache hit
ratio (#cache hits / #total finds) in Interpreter that </FONT></DIV>
<DIV><FONT size=2 face=Arial>I count in internalFindNewMethod, resetting
</FONT><FONT size=2 face=Arial>counters after getting them in
vmParameterAt:.</FONT></DIV>
<DIV><FONT size=2 face=Arial>It keeps the same values whatever the result of the
test is (good or bad) which is a good point,</FONT></DIV>
<DIV><FONT size=2 face=Arial>and it gets better values with n greater
(99.8 % with 32 benchFib).</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Thanks Eliot, I'll keep that in mind for
next benchmark trials :-)</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>regards, </FONT></DIV>
<DIV><FONT size=2 face=Arial>Alain</DIV></FONT>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<DIV>"Eliot Miranda" <<A
href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</A>> a écrit
dans le message de news: <A
href="mailto:AANLkTikQXaGTUdBdau0Ua36p7Mo3gXMVFvV-aUA58-rp@mail.gmail.com">AANLkTikQXaGTUdBdau0Ua36p7Mo3gXMVFvV-aUA58-rp@mail.gmail.com</A>...</DIV>Hi
Alain,
<DIV><FONT size=2 face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT
size=2 face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><BR></DIV>
<DIV> 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.<BR><BR>
<DIV class=gmail_quote>On Fri, May 21, 2010 at 2:37 PM, Alain_Rastoul <SPAN
dir=ltr><<A href="mailto:alr.dev@free.fr">alr.dev@free.fr</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>Right, it has nothing to do with commonSend and
cache.<BR>Being stubborn I added cache hit / misses counters to the vm but
it showed<BR>nothing significant except a very good ratio : 95 to 98%
:)<BR><BR>In addition, putting the squeak process to a lowest priority
(even "idle")<BR>seems to make it run much faster (!!!).<BR>Strange
Windows.<BR><BR>Regards<BR><BR>Alain<BR><BR>"Levente Uzonyi" <<A
href="mailto:leves@elte.hu">leves@elte.hu</A>> a écrit dans le message de
news:<BR>Pine.LNX.4.64.1005211945090.15643@login01.caesar.elte.hu...<BR>
<DIV>
<DIV></DIV>
<DIV class=h5>> On Fri, 21 May 2010, Alain_Rastoul
wrote:<BR>><BR>>> Hello,<BR>>><BR>>> I recently tryed
then 4.1 and discovered a strange behavior that<BR>>>
appearead<BR>>> to be true with the 3.10 also.<BR>>> The test is
simply running benchFib in series of runs.<BR>>> If I run the test 10
times, on of the run is about 2-3 times faster than<BR>>>
the<BR>>> others, and I can't explain that.<BR>>><BR>>> 10
timesRepeat: [<BR>>> | r t |<BR>>> t := Time
millisecondsToRun: [r := 26 benchFib].<BR>>> Transcript show:
((r * 1000) // t) ; cr.<BR>>> ]<BR>><BR>> I can't reproduce
this. I think it's just noise from your OS. But try to<BR>> evaluate
this:<BR>><BR>> [<BR>> ((1 to: 100)<BR>> collect: [
:run |<BR>> (Integer >> #benchFib) flushCache.<BR>>
[ 26 benchFib ] timeToRunWithoutGC ]) sort ] valueAt:
80.<BR>><BR>> If you get the same results, then GC and caching doesn't
change the<BR>> behavior, so you can be pretty sure that it's just
OS-noise. Try<BR>> increasing the priority of Squeak's process and repeat
the tests.<BR>><BR>><BR>> Levente<BR>><BR>>><BR>>>
will give me 10 numbers about 2486297 (one of the runs)<BR>>> but one
run will give me 10 numbers about 6773017.<BR>>> I stopped all I could
stop on my laptop and nothing else but squeak is<BR>>>
running...<BR>>> I made a TimeProfileBrowser and the inner loop of the
profile seems to<BR>>> show<BR>>> that primitives are more than
2 times faster.<BR>>> (and everything seems 2 times
faster)<BR>>> Anybody noticed that (I searched the web but found
nothing) ?<BR>>> primitive calls ?<BR>>>
methodCache?<BR>>><BR>>><BR>>> Best
regards,<BR>>><BR>>>
Alain<BR>>><BR>>><BR>>><BR>>><BR>>><BR>><BR>><BR><BR><BR><BR><BR></DIV></DIV></BLOCKQUOTE></DIV><BR></DIV>
<P></P><FONT size=2 face=Arial></FONT><FONT size=2 face=Arial></FONT>
<HR>
<P></P><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><BR></BLOCKQUOTE></BODY></HTML>