Re: Why does std::chrono now() uses slow syscall?

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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
| #define _GLIBCXX_USE_GETTIMEOFDAY 1
| #define _GLIBCXX_USE_CLOCK_MONOTONIC 1
| #define _GLIBCXX_USE_CLOCK_REALTIME 1
| #define _GLIBCXX_USE_SCHED_YIELD 1
| #define _GLIBCXX_USE_NANOSLEEP 1

which means it doesn't need the syscall version.