Messages in this thread | | | Date | Sun, 7 Nov 1999 17:00:38 -0700 | From | Richard Gooch <> | Subject | RE: gettimeofday being faster than getpid? |
| |
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/
| |