| Frankly, having fought the test vs user-configure battle many times, there comes a point where the user bears some responsibility. This strikes me as one of those times.
For us, at least, creating another startup delay while libevent probes timers would be more than annoying. It is completely reasonable to suggest option 1, and I would greatly prefer it as someone who embeds libevent in a performance-critical package.
On Aug 4, 2011, at 1:55 PM, Jardel Weyrich wrote: The problem I see is that you can't assume system A would be faster with timing mechanism X, or system B with timing mechanism Z. This may vary from device to device. I believe this is not something that can be reliably solved without querying the actual system at runtime.
See
yrs, jardel
On Thu, Aug 4, 2011 at 4:01 PM, Dave Hart <hart@xxxxxxx> wrote:
On Thu, Aug 4, 2011 at 18:36 UTC, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> Hmmm. So as near as I can tell, coming out of this whole discussion, I
> can see a few options for Libevent 2.1:
>
> * Make no changes in the code, but suggest to people that they should
> be using EVENT_BASE_FLAG_NO_CACHE_TIME if they are running on a
> platform where time checking is very quick and they care about very
> accurate timing.
>
> * Do a slightly inaccurate guess about what operating system types
> we're on, and always disable time cacheing on places like Linux/OSX.
> This will create problems like Nicholas mentions above.
>
> * Probe somehow (probably at runtime) to determine whether we're
> someplace that has fast time checking or not.
>
> Option 1 requires no code changes; option 2 is easy; option 3 will
> mean more work tracking down which versions of what are fast, and
> figuring out how to probe correctly, and is more work than I know if I
> can do personally on this.
Option 3 seems like the only sane approach to attempting to
heuristically decide whether or not to cache time-of-day.
Configure-time checks could mislead, as the runtime system may have
binary-compatible but very different behavior, such as Linux due to
different underlying timesource selection.
I'm not sure what you mean about tracking down which versions of what
are fast, though. Can't you simply test the same path libevent will
use to fetch the time? The decision to use CLOCK_MONOTONIC vs.
gettimeofday() could be taken first, then a few queries in a row of
the clock via the selected mechanism and some threshold used to decide
whether to cache or not (perhaps with a way to force the choice, in
case). If the trapping clock reads are 100x slower than the mapped +
TSC approaches, a sane threshold that's reasonably future-proof seems
achievable.
I'm not volunteering to do this, either, I'm afraid.
Cheers,
Dave Hart
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.
|