[zeromq-dev] zmq::poll timeout returns immediately on MacOS/X 10.5

[Marcin Gozdalik]

2010/6/11 Marcin Gozdalik <gozdal at gmail.com>

> 2010/6/11 Steven McCoy <steven.mccoy at miru.hk>
>
>> On 11 June 2010 16:11, Steven McCoy <steven.mccoy at miru.hk> wrote:
>>
>>> "It takes 324 cycles per call to complete 1 million GTOD calls without
>>> RDTSCP and 221 cycles per call with the capability."
>>>
>>>
>>>
>> Compare this with HPET which I clock about 500ns when using mmap(), it
>> would be significantly slower when using libc IO to read from the device.
>>
>> WIthout RDTSCP or HPET you can use CPUID+RDTSC or complicated tracking of
>> current cores and TSC offsets, etc, which is absolutely broken on
>> hyperthreading processors.
>>
>
> A micro-benchmark comparing various time-tracking methods (for FreeBSD but
> probably easily portable) was posted on
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/2008-06/msg00000.htmlOn Linux the fastest is clock_getttime(CLOCK_MONOTONIC_COARSE) (recently
> introduced in 2.6.3X - see http://lwn.net/Articles/347811/)
>

I did some testing on 2 Ubuntu 10.04 machines. The code I used is at
http://gozdal.com/bench_time.c

On the first machine:

uname -a
Linux monster 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010
x86_64 GNU/Linux

/proc/cpuinfo

processor : 0..3
model name : AMD Phenom(tm) II X4 940 Processor
cpu MHz : 3000.000

gozdal at monster:~/workspace/timebench$ ./bench_time 10000000 | sort -rnk1

Timing micro-benchmark.  10000000 syscall iterations.
Avg. us/call Elapsed Name
Value from time(3): 1276256828
Last value from gettimeofday(2): 1276256828.115517
Last value from clock_gettime(2/CLOCK_THREAD_CPUTIME_ID): 7.304321731
Last value from clock_gettime(2/CLOCK_REALTIME): 1276256829.413954584
Last value from clock_gettime(2/CLOCK_REALTIME_COARSE): 1276256829.503674678
Last value from clock_gettime(2/CLOCK_PROCESS_CPUTIME_ID): 5.629295133
Last value from clock_gettime(2/CLOCK_MONOTONIC): 3012.553881518
Last value from clock_gettime(2/CLOCK_MONOTONIC_RAW): 3013.496360362
Last value from clock_gettime(2/CLOCK_MONOTONIC_COARSE): 3013.710833565
0.176539 1.765387 clock_gettime(2/CLOCK_PROCESS_CPUTIME_ID)
0.167505 1.675046 clock_gettime(2/CLOCK_THREAD_CPUTIME_ID)
0.104913 1.049130 clock_gettime(2/CLOCK_MONOTONIC_RAW)
0.065641 0.656409 clock_gettime(2/CLOCK_MONOTONIC)
0.065080 0.650796 gettimeofday(2)
0.065006 0.650058 time(3)
0.064833 0.648334 clock_gettime(2/CLOCK_REALTIME)
0.011304 0.113035 clock_gettime(2/CLOCK_MONOTONIC_COARSE)
0.009635 0.096351 clock_gettime(2/CLOCK_REALTIME_COARSE)

On the second one (MacBook laptop running under Ubuntu 10.04)

Linux gozdal 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010
i686 GNU/Linux

processor : 0..1
model name : Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz
cpu MHz : 2000.000

gozdal at gozdal:~/bench_time$ ./bench_time 1000000 | sort -rnk1
Timing micro-benchmark.  1000000 syscall iterations.
Avg. us/call Elapsed Name
Value from time(3): 1276256889
Last value from gettimeofday(2): 1276256888.761737
Last value from clock_gettime(2/CLOCK_THREAD_CPUTIME_ID): 7.657109212
Last value from clock_gettime(2/CLOCK_REALTIME): 1276256890.434721507
Last value from clock_gettime(2/CLOCK_REALTIME_COARSE): 1276256890.793074738
Last value from clock_gettime(2/CLOCK_PROCESS_CPUTIME_ID): 7.078902976
Last value from clock_gettime(2/CLOCK_MONOTONIC): 508.237703705
Last value from clock_gettime(2/CLOCK_MONOTONIC_RAW): 509.592515633
Last value from clock_gettime(2/CLOCK_MONOTONIC_COARSE): 509.961003092
1.375865 1.375865 gettimeofday(2)
1.354788 1.354788 clock_gettime(2/CLOCK_MONOTONIC_RAW)
1.354032 1.354032 clock_gettime(2/CLOCK_MONOTONIC)
1.350675 1.350675 clock_gettime(2/CLOCK_REALTIME)
0.625702 0.625702 clock_gettime(2/CLOCK_PROCESS_CPUTIME_ID)
0.578193 0.578193 clock_gettime(2/CLOCK_THREAD_CPUTIME_ID)
0.370512 0.370512 clock_gettime(2/CLOCK_MONOTONIC_COARSE)
0.361006 0.361006 clock_gettime(2/CLOCK_REALTIME_COARSE)
0.322257 0.322257 time(3)

It's little surprising to see simple time the fastest on my laptop.

Under MacOS AFAIK there is no clock_gettime

-- 
Marcin Gozdalik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100611/63a1b1d5/attachment.htm>