[BUG] why is frame rate in 3.2.5 slower?

John M McIntosh johnmci at smalltalkconsulting.com
Thu Mar 14 07:31:54 UTC 2002


>>I haven't been following this discussion in detail, but this sounds 
>>like it might be working with the primordial Mac 'ticks' (60/sec) 
>>time unit. I don't suppose there's a newer (OS X?) timer API that 
>>isn't limited to tick resolution?
>>
>>-Martin

Nailed it.
In checkForInterrupts we attempt to keep the number of times we visit 
this area to cluster around interruptChecksEveryNms (5 milliseconds), 
by altering the interruptCheckCounter starting value up or down. This 
value reflects how much work is done in 5 ms and it varies depending 
on the bytecode mix.

Now this is ok on a mac under os-8 because hey you aren't running 
anything else, so we just grab 100% of the CPU.

Ah, now on other more modern (sic) operating systems we need to be 
nice to other clients and surrender the CPU to avoid hogging it. So 
if nothing else is going on in Squeak we invoke 
ioRelinquishProcessorForMicroseconds and surrender the CPU for a 
bunch of microseconds, then look for a new process to dispatch.


Now the problem is we that we've calculated a target number of 
bytecodes per second (kinda) and suddenly here we stop! You see if a 
Delay happens as in this simple test case it stops the current 
process, and we don't find another to run so we issue a relinquish 
processor. In fact we can see that Squeak is only using 20-30% of the 
CPU working on this iteration of delay for 1 ms test.

So the ioRelinquishProcessorForMicroseconds call messes up the calculation.

So why the cluster around 1/60 of a second?
Well mmm don't know... because of the following

I changed my ioRelinquishProcessorForMicroseconds to do
	GiveUPControlToCPU();
         if (nextWakeupTick != 0 && ioMSecs() >= nextWakeupTick)
             interruptCheckCounter = 0;


Somehow I thought the os-x scheduler snatchs control away for 1/60 of 
a second, but that doesn't jive because running the test with this 
change gives

a SortedCollection(815->1 179->2 3->3 2->6 1->5)
and the framerate morphic shows 47-49

I not expect to see 815 at 1ms if GiveUPControlToCPU() actually took 
1/60 of a second.

So I'll open the floor for discussion and maybe the other VM 
implementors can go away and try this out. So our choices are:

a) use a timmer to fire every N ms (1, 2, 5?) Pick please (and 
overhead?) Note I have a check     if (nextWakeupTick != 0) 
interruptCheckCounter = 0; and I also recalculate the lowresolution 
timer every 16ms based on a counter here in this timmer function.

or

b) install patch in ioRelinquishProcessorForMicroseconds, also alter 
interruptChecksEveryNms to a smaller number 2,3, or 4?


Note:

(b) might only be feasible in a majority of implementations due to 
timer overhead or lack of high resolution timers.

So comments gents?

PS I'll post some performance numbers, tomorrow! Bed beckons

-- 
--
===========================================================================
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