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