[comp.sys.amiga] Timing programs

harald@boink.UUCP (Harald Milne) (05/29/90)

In article <2874@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes:
> Well, you may be surprised how difficult it is to "calibrate" these timing
> tools. On a 68000, it is tricky, when you move up to an '020 or '030, life
> gets really interesting.
> 
> Basically, getting micro-second accuracy in timing requires specialized 
> hardware.

    This is what the CiaTimer code would buy you. An asynchronous hardware
timer running independently of CPU execution/variations.

> Even then, there are many pitfalls associated with interrupts.

    I cleaned all the problems I found in CiaTimer. 

    All said and done, I was getting very repeatable (and very respectable)
+/- 1 micro second resolution. The repeatability was my prime concern however.
I realize fine tuning for instruction execution is probably a lost cause, but
having a repeatable time (for example, algorithms that exihibit known and
repeatable execution) was all I needed to show up differences in speed when
the algorithm was tweeked. A very useful performance tool, since the effect
of any optimisations are readily appearent.

    Maybe I'll look at the profiling tools supplied by Lattice and Manx, and
see if there is any use for it there. I have not used them, and I wouldn't
be at all suprised if the performance wasn't up to par.

    Having a UNIX alarm call, or even a BSD ualarm call (that's a micro second
alarm event) would be nice too. Tie this into task private exception/signal,
and it would be very useful.

> Stanley Chow        BitNet:  schow@BNR.CA
> BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
> (613) 763-2831		     ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185
> Me? Represent other people? Don't make them laugh so hard.

-- 
Harald Milne                   RISCy business	       uunet!ccicpg!boink!harald