On Sat, 6 Jul 2019 at 22:28, Paul Smith <psmith@xxxxxxx> wrote: > > 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. There are performance penalties to using it too, so it's not just a case of saying "hey, you should use this!" If you link to librt on GNU/Linux then you get a dependency on libpthread which causes libstdc++ to always assume your program is multithreaded, and use atomic ops for reference counting even in single-threaded programs.
