faster gettimeofday?
in [Unix Programming]
|
From: Scott Lurndal on 8 Mar 2010 19:43 Casper H.S. Dik <Casper.Dik(a)Sun.COM> writes: >Rick Jones <rick.jones2(a)hp.com> writes: > >>I like gethrtime() - works great for things like netperf time >>histograms. > >>That Solaris gettimeofday() would be a wrapper around gethrtime() is >>interesting - the Solaris manpage for gethrtime() talks about how it >>is "not correlated in any way to the time of day" which naturally, is >>fine for delta time measurements, but it would seem that the "fairly >>thin wrapper" would have to do all those things a "normal" >>gettimeofday() call would so the result would indeed represent the >>time of day. > >In Solaris, gettimeofday() is implemented as a "fast-trap" and not as an >ordinary system-trap. Any such trap could now sufficient information >to map gethrtime() to tod. SVR4/Unixware had reserved read-only page in the application virtual address space that could be mapped into the application (silently, the first time gettimeofday() was called). This page had the current TOD at a fixed location (and was updated out of the kernel timer routines); this turned gettimeofday() into a simple memory reference. IIRC they did this to improve Oracle performance. scott
From: Rick Jones on 8 Mar 2010 21:05 Casper H.S. Dik <Casper.Dik(a)sun.com> wrote: > Rick Jones <rick.jones2(a)hp.com> writes: > >That Solaris gettimeofday() would be a wrapper around gethrtime() > >is interesting - the Solaris manpage for gethrtime() talks about > >how it is "not correlated in any way to the time of day" which > >naturally, is fine for delta time measurements, but it would seem > >that the "fairly thin wrapper" would have to do all those things a > >"normal" gettimeofday() call would so the result would indeed > >represent the time of day. > In Solaris, gettimeofday() is implemented as a "fast-trap" and not > as an ordinary system-trap. Any such trap could now sufficient > information to map gethrtime() to tod. Ah, good - so two threads or two processes could be making calls to gettimeofday() and "time" will do the right thing bewteen them. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Rick Jones on 8 Mar 2010 21:08 Scott Lurndal <scott(a)slp53.sl.home> wrote: > SVR4/Unixware had reserved read-only page in the application virtual > address space that could be mapped into the application (silently, > the first time gettimeofday() was called). This page had the > current TOD at a fixed location (and was updated out of the kernel > timer routines); this turned gettimeofday() into a simple memory > reference. IIRC they did this to improve Oracle performance. That is great if all you need for the precision of the gettimeofday() call is the resolution of the timer, but these days it seems that many implementations will try to go beyond that, which (IIRC) makes such a memory mapped page, well, difficult :) All those interval counters chugging along in the processors or the HPET etc etc are very enticing. rick jones -- I don't interest myself in "why." I think more often in terms of "when," sometimes "where;" always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Scott Lurndal on 9 Mar 2010 12:58 Rick Jones <rick.jones2(a)hp.com> writes: >Scott Lurndal <scott(a)slp53.sl.home> wrote: >> SVR4/Unixware had reserved read-only page in the application virtual >> address space that could be mapped into the application (silently, >> the first time gettimeofday() was called). This page had the >> current TOD at a fixed location (and was updated out of the kernel >> timer routines); this turned gettimeofday() into a simple memory >> reference. IIRC they did this to improve Oracle performance. > >That is great if all you need for the precision of the gettimeofday() >call is the resolution of the timer, but these days it seems that many >implementations will try to go beyond that, which (IIRC) makes such a >memory mapped page, well, difficult :) All those interval counters >chugging along in the processors or the HPET etc etc are very >enticing. So put a very high res timer in the northbridge and have it respond to some address above top of high memory. No interrupts and nanosecond resolution, and a simple memory reference if that physical address is mapped read-only into the application. The memory controller just needs to reserve a 4k page and update it itself; the access will be at full memory speed (but non-cachable). scott
From: Chris Friesen on 9 Mar 2010 14:46
On 03/09/2010 11:58 AM, Scott Lurndal wrote: > So put a very high res timer in the northbridge and have it respond > to some address above top of high memory. You mean like mapping /dev/hpet on modern x86 systems running linux? :) I seem to remember an architecture (maybe Sparc?) that distributed a fast-but-not-insanely-fast clock pulse to all cpus. Like 1MHz or something similar. This was fast enough to be useful but not so fast that clock skew becomes significant. This then incremented a counter in each cpu which could be read in a single instruction. Chris |