It's a (very) minor point, orthogonal to gettimeofday() performance,
but the *first* thing that struck me about the test code
(http://pastebin.com/m311250a6) was "why do (two!) double-precision
floating-point divides by 1000000.0 instead of multplying by 1.0e-6?".
Indeed, doing two integer-to-double-precision conversions is also
unnecessary: the expression can be rewritten as
(tod_now.tv_sec - tod_then.tv_sec) +
1.0e-6 * (double)(tod_now.tv_usec - tod_then.tv_usec)
This doesn't make a significant difference here, but in an inner loop
divides and int-to-floats can be a significant performance hit: On
most modern processors floating-point add and multiply are fully
pipelined, and take 2-4 clock cycles, while divide is not pipelined,
and takes 20-50 cycles for double precision.
The second thing was struck me about the test code was that gcc points
out the absence of a prototype for checkval() . :)
And the third thing that struck me was that this test gives a falsely
optimistic picture of gettimeofday() performance in an actual application,
because in this test we can expect all the code paths to be hot in the
caches, whereas in an actual application there's lots of other code and
data (both userland and kernel) competing for the cache.
Apart from these nits... my results on a Thinkpad T41p (i386 Pentium M)
running 4.2-stable are (test program compiled with gcc 4.2.0, -g -O2):
... with 'apm -H' in effect (clock speed 1.7GHz): 2.92 seconds
... with 'apm -L' in effect (clock speed 0.6GHz): 3.98 seconds
So the time is quite nonlinear with clock speed: cutting the clock
rate by a factor of 2.83 only increased the time by a factor of 1.36.
This is consistent with the need for nontrivial housekeeping to talk
to (synchronize with) external devices in the kernel timecounter code.
Yours for nanoseconds,
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
School of Mathematics, U of Southampton, England
"Floating point numbers are like sandpiles; every time you move one
you lose a little sand and pick up a little dirt" -- Victor Vyssotsky
