On Tue, Aug 07, 2012 at 05:00:59PM -0700, Leo Alterman wrote:
> 64-bit glibc appears to avoid syscalls for clock_gettime(), so we can get
> higher resolution timing and avoid having a timer firing off SIGALRM
> without introducing extra overhead.
>
> Signed-off-by: Leo Alterman <[email protected]>
I'd heard that this was fast on Linux x86-64, but I'd never tested
it. That seems like a good idea before committing it, so I wrote the
following program:
#include <stdio.h>
#include <time.h>
int
main(void)
{
struct timespec start, end;
int i;
clock_gettime(CLOCK_MONOTONIC, &start);
for (i = 0; i < 1000000; i++) {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
}
clock_gettime(CLOCK_MONOTONIC, &end);
printf("%.3f nsec per call\n",
(1000000000.0 * (end.tv_sec - start.tv_sec)
+ end.tv_nsec - start.tv_nsec) / 1000000.0);
return 0;
}
and ran it on identical i386 and x86-64 Debian GNU/Linux "wheezy"
prerelease systems with gcc version 4.6.3 and eglibc 2.13-33,
compiling without out any optimizations.
On i386: about 312 nsec per call.
On x86-64: about 29 nsec per call.
Changing CLOCK_MONOTONIC to CLOCK_REALTIME doesn't change the speed.
When I comment out the clock_gettime() call on either system, it's
about 3 nsec per "call", which one can figure as the overhead of the
loop.
So, my take is that this is fast enough on x86-64 to drop the caching.
(This isn't a review of your code, just an analysis of whether it's a
worthwhile change.)
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
