On Mon, 2 Jun 2008, Sean Chittenden wrote:
I wouldn't expect SMP to make much difference between CLOCK_REALTIME and
CLOCK_REALTIME_FAST. The only difference is that the former calls
nanotime() where the latter calls getnanotime(). nanotime() always does
more, but it doesn't have any extra SMP
On Mon, 2 Jun 2008, Sean Chittenden wrote:
rozetta~/devel/c%>sysctl hw.model
hw.model: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz
rozetta~/devel/c%>./bench_time 9079882 | sort -rnk1
Timing micro-benchmark. 9079882 syscall iterations.
Avg. us/callElapsed Name
1.40546912
On Mon, 2 Jun 2008, Gary Stanley wrote:
At 06:19 AM 6/2/2008, Bruce Evans wrote:
These are very slow. Are they on a 486? :-) I get about 262 ns for
CLOCK_REALTIME using the TSC timecounter on all ~2GHz UP systems.
The syscall overhead is about 200 nsec (170 nsec for a simpler syscall
and may
On Mon, 2 Jun 2008, Gary Stanley wrote:
At 06:55 AM 6/2/2008, Bruce Evans wrote:
On Mon, 2 Jun 2008, Gary Stanley wrote:
At 12:54 AM 6/2/2008, Sean Chittenden wrote:
PS Is there a reason that time(3) can't be implemented in terms of
clock_gettime(CLOCK_SECOND)? 10ms seems precise enough co
At 06:19 AM 6/2/2008, Bruce Evans wrote:
These are very slow. Are they on a 486? :-) I get about 262 ns for
CLOCK_REALTIME using the TSC timecounter on all ~2GHz UP systems.
The syscall overhead is about 200 nsec (170 nsec for a simpler syscall
and maybe 30 nsec extra for copyin/out for clock_
At 06:55 AM 6/2/2008, Bruce Evans wrote:
On Mon, 2 Jun 2008, Gary Stanley wrote:
At 12:54 AM 6/2/2008, Sean Chittenden wrote:
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
rozetta~/devel/c%>sysctl hw.model
hw.model: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz
rozetta~/devel/c%>./bench_time 9079882 | sort -rnk1
Timing micro-benchmark. 9079882 syscall iterations.
Avg. us/callElapsed Name
1.40546912.761494 clock_gettime(2/CLOCK_REALTIME)
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 an
On Sun, 1 Jun 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)
On Mon, 2 Jun 2008, Claus Guttesen wrote:
% ./bench_time 9079882 | sort -rnk1
Timing micro-benchmark. 9079882 syscall iterations.
Avg. us/callElapsed Name
9.32248484.647053 gettimeofday(2)
8.95532481.313291 time(3)
8.64831578.525684 clock_gettime(2/CLOCK_RE
On Mon, 2 Jun 2008, Gary Stanley wrote:
At 12:54 AM 6/2/2008, Sean Chittenden wrote:
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 get
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) w
> 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 an
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 an
14 matches
Mail list logo
