[BUG] why is frame rate in 3.2.5 slower?

John M McIntosh johnmci at smalltalkconsulting.com
Thu Mar 14 23:32:35 UTC 2002


First I need some beta testers to kick the tires, email me if interested.

I've made some changes and have done some testing. I saw some 
performance issues with resetting interruptCheckCounter every 
millisecond, and of course that doesn't help for platforms that don't 
have timers you can abuse.

So in
ioRelinquishProcessorForMicroseconds(int microSeconds)

I have code similar to this (I thought about sticking this in 
Interpret but decided we can wait a bit for some more feedback from 
VM folks).

     interruptCheckCounter = 0;
     now = (ioMSecs() & 536870911);
     if (nextWakeupTick <= now)
         if (nextWakeupTick == 0)
             realTimeToWait = 16;
         else
             return;
     else
         realTimeToWait = nextWakeupTick - now;

     GiveUpControlToTheCPUForThisAmountOfMilliSecondsMoreOrLess(realTimeToWait).


Now when Squeak is idle we actually are asked to wait 18 or so ms as 
part of the Morpic step process. In the past this logic would do 1ms 
waits, 18 times...
Here we attempt to wait upto the nextWakeupTick which is when the 
next delay finishes. Note we set the interruptCheckCounter to zero 
because either the wake up time is in the past, or we should delay 
for that amount of time. I also set the realTimeToWait to 16 if no 
delays are pending (ah, certainly not a possibility in 3.x images). 
Clock rollover is handled in checkForInterrupts so I don't bother 
with it here.

Benefit (1) CPU consumption for idle Squeak goes down. (yes I measured that)

GiveUpControlToTheCPUForThisAmountOfMilliSeconds might end early? or 
late? Right now Morphic is issuing < 20ms delays when idle. Depending 
on how the delay works you might get control back early based on 
outside interrupts. Not sure if this is required on the mac since we 
have a different pthread watching the UI, and we *are* waking up 
50-60 times a second which is at the resolution we seem to get events 
at anyway. (Milage might vary, complain to the VM guy). Technically I 
do a pthread_cond_wait but don't let that cloud  your implementation 
decision. I had tried select on os-x but that had some odd behavior...

So if we do the check 1ms delays at idle we get
(897->1 100->2 2->3 1->4)

which seems reasonable. Now just to change things I run the same 
benchmark when Squeak is busy.

check 1ms delays when busy background task
checks are about every 5 ms via interruptChecksEveryNms

(2->1 4->2 131->3  427->4 175->5  123->6 101->7 14->8  4->22 3->9 
3->23  2->15 2->24 2->25 1->11 1->13 1->14 1->16 1->18 1->19 1->20)

now if I change interruptChecksEveryNms to 3ms I get

(454->2  457->3 73->4 2->5 4->6 1->7  1->12 1->13 1->14  3->21  2->20  1->22)

So with interruptChecksEveryNms at about 3ms tinyBenchMarks gives

45616535 bytecodes/sec; 1428393 sends/sec
45197740 bytecodes/sec; 1454614 sends/sec
45454545 bytecodes/sec; 1467441 sends/sec
45325779 bytecodes/sec; 1483136 sends/sec
45261669 bytecodes/sec; 1477867 sends/sec
45007032 bytecodes/sec; 1467441 sends/sec
45390070 bytecodes/sec; 1453344 sends/sec
45197740 bytecodes/sec; 1481815 sends/sec
44943820 bytecodes/sec; 1481815 sends/sec
45038705 bytecodes/sec; 1461000 sends/sec


Now lets compare that to checking every 1 ms based on a timer pop. 
These are the earlier numbers I sent to the list. So as you can see 
the values are a bit slower. Mind we don't have quite the delay 
accuracy if Squeak is 100% busy. But I'm trading accuracy for 
performance here.

a SortedCollection(882->1 115->2 3->3)

41967213 bytecodes/sec; 1384425 sends/sec
42022324 bytecodes/sec; 1383274 sends/sec
42160737 bytecodes/sec; 1384425 sends/sec
42160737 bytecodes/sec; 1397211 sends/sec
42049934 bytecodes/sec; 1398385 sends/sec
41830065 bytecodes/sec; 1398385 sends/sec
41504539 bytecodes/sec; 1398385 sends/sec
41423948 bytecodes/sec; 1397211 sends/sec
42188529 bytecodes/sec; 1398385 sends/sec
42188529 bytecodes/sec; 1398385 sends/sec

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================



More information about the Squeak-dev mailing list