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.
