Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> wrote:

> But this one gives
> 
>  (778->10 110->9 18->7 16->2 15->8 13->13 12->1 10->11 9->5 8->3 7->6 3->4 1->14)
> 
> which looks really bad - or is my machine just too slow?
> 
> 0 tinyBenchmarks '48632218 bytecodes/sec; 1671345 sends/sec'
> 

I get very similar results.



> > I noticed that even after fixing the raw timer accuracy, the second one
> > still lagged. The solution I found was to use an OS timer callback which
> > had to reset the interruptCheckCounter in order to force a check for
> > pending delay timeouts. This slightly decreases general performance
> > (since you're checking 1000 times/sec) but it was less then 1% and gives
> > very exact results. It turns out that after these changes I was able to
> > _drastically_ reduce the sound player's buffer size without noticable
> > distortion.
> 
> Hmm, this might be a desirable option for the Unix VM ...
> 

Well where is the delay coming from?  These times look suspiciously
close to the time quantum on Linux, which is 10 milliseconds.  I don't
know all Linux kernel innards by any means, but perhaps the schedular
only runs every 10 ms, even if the system is idle?

This points to a general problem: if the system is *not* idle, then
there is no way Squeak will get woken up quickly, because the other
process will have gotten onto the CPU and won't give it up until it's
10 ms quantum is over.


But still, a lot of times Squeak is the only active process.  A funny thing
about desktop computers is that, unless you are running something
ridiculous like MS Internet Explorer, they tend to sit idle all the time.
So what to do?

Well, Squeak is doing the standard Unix thing of waiting in select().  Shouldn't this
be all that is required?  If there is a better algorithm for short sleeps, then select()
should certainly be fixed to use it.  Then again, maybe there is no way, and that's why
usleep() is giving us what we see.  Does anyone feel like bugging the Linux
kernel and/or libc guys for ideas?


Also, I wonder how other Unices do with this....


-Lex


PS -- good find, Andreas!