On 11 June 2010 13:16, Martin Sustrik <span dir="ltr"><<a href="mailto:sustrik@250bpm.com">sustrik@250bpm.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Let me explain the problem: To do exact timouts, zmq_poll would have to</div>
measure exact time (gettimeofday) at the beginning of the function. If<br>
it doesn't know the time it was invoked, it cannot terminate at right time.<br>
<br>
This time measurement is the impact I am speaking of. Although it may<br>
seem negligible, in a tight loop it can decrease overall throughput (I'm<br>
guessing here) by ~30%.<br>
<br>
One way to solve the problem would be to use some fast mechanism (such<br>
as rdtsc on x86/64) to find out whether noticeable time has elapsed<br>
since last call to zmq_poll (say at least 1ms), call gettimeofday only<br>
if it did, and use the previous time measurement if it didn't.<br>
<br>
Of course, this would leave non-x86 platforms with the full performance<br>
impact.</blockquote><div><br></div><div> With Nehalem you should be using gettimeofday() as it's now using rdtscp which apparently solves world hunger according the LKML.  On SPARC, RS6000, PA-RISC gettimeofday() is already light so the only issue would appear to be older x86 platforms and possibly the embedded range which performance is kind of moot anyway.</div>

<div><br></div><div>-- </div><div>Steve-o</div></div>