On Sat, 2019-07-06 at 12:10 -0400, Paul Smith wrote: > On Sat, 2019-07-06 at 18:29 +0300, Alexander Monakov wrote: > > ^ this is a problem, your libstdc++ library is configured to use the syscall > > directly instead of letting the libc go via the VDSO fastpath. > > Oh snap! OK I've delved into this. I guess it's intended behavior, although it seems a little magic. Basically if your sysroot does not have at least glibc 2.17 then the libstdc++-v3 configure script will always choose the slower, syscall versions of clock_gettime() even if a faster version is available (in the rt library). You can work around this issue by forcing the libstdc++-v3 configure to use the rt library, by adding this configure option: --enable-libstdcxx-time=rt There is some discussion of this in the libstdc++ manual section on configuration: https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html but it's not likely something you'll stumble upon on your own, and it definitely isn't made clear the performance penalties you might pay if you don't use it. It might be useful to at least discuss this in the docs, although I suppose systems using glibc <2.17 are getting more rare every day. Thanks for the heads-up!
