From owner-freebsd-performance@FreeBSD.ORG Mon Jun 2 05:22:11 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D6C1065672 for ; Mon, 2 Jun 2008 05:22:11 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from davie.textdrive.com (davie.textdrive.com [207.7.108.101]) by mx1.freebsd.org (Postfix) with ESMTP id C42AC8FC1C for ; Mon, 2 Jun 2008 05:22:11 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from [192.168.255.187] (dsl093-167-029.sfo1.dsl.speakeasy.net [66.93.167.29]) by davie.textdrive.com (Postfix) with ESMTP id D575AC3051 for ; Mon, 2 Jun 2008 04:54:38 +0000 (GMT) Message-Id: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> From: Sean Chittenden To: freebsd-performance@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Sun, 1 Jun 2008 21:54:36 -0700 X-Mailer: Apple Mail (2.924) Subject: Micro-benchmark for various time syscalls... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 05:22:12 -0000 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. % ./bench_time 9079882 | sort -rnk1 Timing micro-benchmark. 9079882 syscall iterations. Avg. us/call Elapsed Name 9.322484 84.647053 gettimeofday(2) 8.955324 81.313291 time(3) 8.648315 78.525684 clock_gettime(2/CLOCK_REALTIME) 8.598495 78.073325 clock_gettime(2/CLOCK_MONOTONIC) 0.674194 6.121600 clock_gettime(2/CLOCK_PROF) 0.648083 5.884515 clock_gettime(2/CLOCK_VIRTUAL) 0.330556 3.001412 clock_gettime(2/CLOCK_REALTIME_FAST) 0.306514 2.783111 clock_gettime(2/CLOCK_SECOND) 0.262788 2.386085 clock_gettime(2/CLOCK_MONOTONIC_FAST) Last value from gettimeofday(2): 1212380080.620649 Last value from time(3): 1212380161 Last value from clock_gettime(2/CLOCK_VIRTUAL): 2.296430000 Last value from clock_gettime(2/CLOCK_SECOND): 1212380338.000000000 Last value from clock_gettime(2/CLOCK_REALTIME_FAST): 1212380243.461081040 Last value from clock_gettime(2/CLOCK_REALTIME): 1212380240.459788612 Last value from clock_gettime(2/CLOCK_PROF): 185.560343000 Last value from clock_gettime(2/CLOCK_MONOTONIC_FAST): 5747219.271879584 Last value from clock_gettime(2/CLOCK_MONOTONIC): 5747216.886509281 [1] http://sean.chittenden.org/pubfiles/freebsd/bench_time.c [2] sys/time.h comments about precision. http://fxr.watson.org/fxr/source/sys/time.h#L269 -- Sean Chittenden sean@chittenden.org http://sean.chittenden.org/