[M3devel] Fwd: Why does std::chrono now() uses slow syscall?

Jay jay.krell at cornell.edu
Tue Jan 28 00:13:46 CET 2014

Hints for how m3core/libm3 should get time efficiently...

 - Jay

Begin forwarded message:

> From: Jonathan Wakely <jwakely.gcc at gmail.com>
> Date: January 26, 2014, 2:33:36 AM PST
> To: Keith Erickson <kerickso at pppl.gov>
> Cc: gcc-help <gcc-help at gcc.gnu.org>
> Subject: Re: Why does std::chrono now() uses slow syscall?
> On 26 January 2014 07:50, Keith Erickson wrote:
>> My questions, then, are....  why would I ever want to use the syscall
>> version?  It seems that configure prefers it, and will use it if it's
>> available.
> It prefers to use clock_gettime and only uses the syscall if a
> configure test using clock_gettime(CLOCK_MONOTONIC, &tp) fails.
>> But it's stupidly slow, even on the fasted server CPU that
>> AMD sells (Opteron 6386 SE at the time of this writing).  How do I not
>> use this slow method?  Do I have to compile gcc specially?  What are
>> the drawbacks to forcing configure to not set that #define?  Is there
>> an approved way to tell configure to use a fast time?
> Prior to glibc 2.17 clock_gettime was in librt.so not libc.so, which
> is not used automatically by libstdc++. To tell configure to use it
> you need to build GCC with --enable-libstdcxx-time=rt, but that means
> that libstdc++.so will be linked to librt.so which depends on
> libpthread.so which means that the library always thinks it is part of
> a multithreaded application and so even single-threaded programs use
> atomic operations for internal reference-counting (e.g. in std::string
> and std::shared_ptr).  That's why we don't use clock_gettime unless
> explicitly configured to do so.
> With glibc 2.17 or later clock_gettime will be used automatically,
> because the functions were moved out of librt.so.
> On my Fedora 20 system I get
> | #define HAVE_SYS_TIME_H 1
> which means it doesn't need the syscall version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140127/d9369ca7/attachment-0001.html>

More information about the M3devel mailing list