wait 0 doesn't

[Ken Norris]

**********
> Date: Wed, 30 Apr 2003 07:08:33 +1000
> Subject: Re: wait 0 doesn't
> From: David Vaughan <dvk at dvkconsult.com.au>
> 
> 
> On Wednesday, Apr 30, 2003, at 02:01 Australia/Sydney, Jim Hurley
> <jhurley at infostations.com> wrote:
>> P.S.
>> 
>> There is an interesting difference between the Mac and PC.
>> 
>> On my  Mac, running the handler:
>> 
>> on mouseUP
>> put empty into field 1
>> repeat 20
>> put the milliseconds into startTime
>> repeat 200
>> wait 1 milliseconds
>> end repeat
>> put  the milliseconds - startTime & comma & space after results
>> end repeat
>> put results  into field 1
>> end mouseUP
>> 
>> I get the following results:
>> 
>> 411, 379, 293, 371, 376, 370, 359, 297, 367, 371, 370, 809, 368, 302,
>> 365, 357, 291, 371, 374, 373
>> 
>> with a minimum of 291 and a maximum of 809.
>> 
>> On my PC I get:
>> 
>> 328, 329,329, 331, 329, 329, 329, 331, 329, 330, 329, 329, .....
>> 
>> with  a minimum of 329  and a maximum of 331.
>> 
>> It doesn't appear to be a memory allocation problem. I have 54 megs
>> allocated to  RunRev on my Mac.
> 
> Not memory, but your OS, what it is doing and how it goes about it. I
> infer from your saying "I have 54 megs allocated..." that you are using
> OS 9. That OS uses co-operative multi-tasking - after yielding in each
> event loop, Rev can continue when the OS or any other task deigns to
> return control. This would account for very high variability. I ran
> your loop on OS X (667MHz TiBook) and obtained figures from 314 to 413,
> averaging 350. It is tighter because of pre-emptive multi-tasking, but
> variable because I happened to have thirteen other user applications
> (and N system tasks) open at the time, not all of them fast asleep. I
> suspect that when you tested on your PC you had fewer interferences. In
> any event, I very much doubt it is a Rev implementation problem.
----------
I agree. Under the current von Neumann model for computer architecture,
everything still passes down the bus in a train, so multitasking is really a
smoke-and-mirrors illusion. Earlier Mac OS' tried to spread stuff out, but
it seemed to give prority to the OS' housekeeping stuff, so differences in
timing were more dramatic on my PB 1400 PPC under OS 8.6 than on an old 68K
Quadra under OS 7.6.1 because of the energy conservation tasks. The data it
returned in HyperCard was more different from OS to OS than from processor
to processor.

The software you run on any machine has to comply with the OS, so IMHO,
unless you can hold off the OS' normal autonomic tasks while your software
deals with clock addresses, the data will get interrupted and lose some
accuracy and consistecy.

I don't pretend to understand OSX, but if it uses a pre-emptive method for
multitasking, then it may allow OS tasking to be held while timing device
addresses are accessed by the software. That would, indeed, make for more
accuracy and consistency. I'd bet that means OSX is very regressive on
machines with slower processors, yes?

Ken N.