Date: Mon, 21 Jul 1997 17:39:57 -0400 (EDT)
Message-Id: <199707212139.RAA04369@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: Anthony DOT Appleyard AT umist DOT ac DOT uk
CC: djgpp AT delorie DOT com
In-reply-to: <5AD5E65CCE@fs2.mt.umist.ac.uk> (MCLSSAA2@fs2.mt.umist.ac.uk)
Subject: Re: Standard tiiming func's & O3+ cause odd errors
Precedence: bulk


> From: "Anthony.Appleyard" <MCLSSAA2 AT fs2 DOT mt DOT umist DOT ac DOT uk>
>   Nate Eldredge <eldredge AT ap DOT net> wrote:-
> > Although CLOCKS_PER_SEC claims to be about 1000000, in reality the 55 ms
> > timer ticks are just scaled to produce the clock() output, leading to big
> > jumps. ...
> 
>   Oh indeed!?!?!?! Then how genuinely can a Gnu C/C++ program time a process
> to the nearest microsecond or so???

Sigh.  CLOCKS_PER_SEC is 91.  UCLOCKS_PER_SEC is 1193180.

The clock() function is accurate to 1/18.2 sec; the "91" is there so
that everything is (sort of) integer math.

The uclock() function really is accurate to better than 1uS.  It uses
the hardware timing chip, which often doesn't work in Win95 but does
elsewhere.