RE: gettimeofday being faster than getpid?
Richard Gooch (rgooch@ras.ucalgary.ca)
Sun, 7 Nov 1999 17:00:38 -0700
Bret Indrelee writes:
> Pavel Machek [mailto:pavel@bug.ucw.cz] wrote:
> > I did some tests, and when I replace getuid() or getpid() with
> > gettimeofday(), it actually gets faster.
> [ snip ]
> > void main(void)
> > {
> > struct timeval tv1, tv2, tv3;
> >
> > gettimeofday(&tv1, 0);
> > getuid(); <--- here
> > gettimeofday(&tv2, 0);
> >
> > printf("Time1: %d:%d\n", tv1.tv_sec, tv1.tv_usec);
> > printf("Time2: %d:%d\n", tv2.tv_sec, tv2.tv_usec);
> > }
>
> Not a very accurate way of measuring.
>
> Might I suggest:
>
> volatile int dummy1, dummy2;
> int loop;
>
> dummy2 = rand();
>
> gettimeofday(&tv1, 0);
> for (loop = 500000; loop >0 ; loop--) {
> dummy1 = dummy2 + 10;
> }
> gettimeofday(&tv2, 0);
>
> gettimeofday(&tv3, 0);
> for (loop = 500000; loop >0; loop--) {
> dummy1 = dummy2 + 10;
> statement_to_be_timed;
> }
> gettimeofday(&tv4, 0);
>
> This gets you a longer run time, minimizing errors in clock accuracy, and
> allows you to subtract the (admittedly extremely limited) loop overhead.
> Provided that the statement under measurement doesn't exceed the size of L1
> cache, the results should give you a fair estimate of the time required to
> execute it.
>
> Not that lval1 and lval2 must be marked volatile in order to prevent
> optimization from eliminating them. It is still possible for the optimizer
> to inline all the statements, but hopefully it will realize that is worse
> because of cache effects than just running the loop.
>
> If the statement does exceed the size of L1 cache, your probably better off
> just putting it in the loop and measuring. The time to execute the loop will
> be totally overwhelmed by the time executing your statement.
>
> You would have to flush cache inside the loop in order to determine how long
> an uncached call takes.
I'd urge you to use lmbench instead. It's got an easy to use test
harness and does a good job at getting accurate and consistent
results. It runs the syscall many times, warms the cache and computes
the median.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/