At 12:54 AM 6/2/2008, Sean Chittenden wrote:
I wrote a small micro-benchmark utility[1] to test various time
syscalls and the results were a bit surprising to me. The results
were from a UP machine and I believe that the difference between
gettimeofday(2) and clock_gettime(CLOCK_REALTIME_FAST) would've been
bigger on an SMP system and performance would've degraded further with
each additional core.
clock_gettime(CLOCK_REALTIME_FAST) is likely the ideal function for
most authors (CLOCK_REALTIME_FAST is supposed to be precise to +/-
10ms of CLOCK_REALTIME's value[2]). In fact, I'd assume that
CLOCK_REALTIME_FAST is just as accurate as Linux's gettimeofday(2) (a
statement I can't back up, but believe is likely to be correct) and
therefore there isn't much harm (if any) in seeing clock_gettime(2) +
CLOCK_REALTIME_FAST receive more widespread use vs. gettimeofday(2).
FYI. -sc
PS Is there a reason that time(3) can't be implemented in terms of
clock_gettime(CLOCK_SECOND)? 10ms seems precise enough compared to
time_t's whole second resolution.
Another interesting idea is to map gettimeofday() to userland, sort
of like darwin (commpage) and linux (vsyscall) via read only page.
Can you try changing microtime() in kern_time.c:gettimeofday() to
getmicrotime() to see if your benchmarks change any?
Also; what clock are you using for your benchmarks? ACPI? TSC?
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
