🚀 go-pugleaf

"John Herbster (TeamB)" <herb-sci at novus-tele.net> wrote in message
news:3ddeb2b6$1@newsgroups.borland.com...
> "David J Taylor" <davidtaylor@writeme.com> wrote
> > > For performance measures, though, RDTSC is the better thing to use.
> >
> > Why?
>
> (1) RDTSC has higher resolution.
> (2) RDTSC requires fewer cycles to fetch readings.
> (3) Clock cycles are easier (for me) to relate to
>  machine instruction times than are nanoseconds.
> --JohnH

Agreed on (1) and (2).  (3) I think is less relevant because what matters
to the end user is time, not cycles.  (Bill also commented on resolution -
thanks).

However, I think there is a need to be careful about measuring too small
an interval because of the way that CPU and OS caching behaves.  Once code
or data is in the CPU cache (or cached from disk) a program can perform
substantially faster.  In all of my measurements:

- I skip measuring the first pass or two
- I try and time chunks of code that are reasonably large and in some way
meaningful to the program function - I'm talking of a few hundred
microseconds here.
- I average the time over the passes of the program (my programs typically
produce regualr graphical updates)

In these circumstances, the microsecond resolution of
QueryPerformanceCounter is adequate for me.

For anyone else reading the thread - the other reminder is that usually
changing the algorithm is far more important than saving one or two CPU
cycles!

Cheers,
David