On Sun, 7 Jul 2019 at 21:18, Paul Smith <psmith@xxxxxxx> wrote: > > On Sun, 2019-07-07 at 20:31 +0100, Jonathan Wakely wrote: > > > 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. > > Yes, that information is presented in the docs, which is good. But I > think the other side of this (that selecting "rt" on older glibc > implementations will give a 22-24% performance increase when calling > steady_clock() / system_clock()) should also be mentioned. > > Unless you're building for a very specific target/need, you likely will > want your compiler to be able to be able to create multi-threaded > programs. I'm not sure what you mean here. The compiler is able to create multi-threaded programs either way. The issue is whether single-threaded programs pay a cost that's only needed by multi-threaded programs or not. With the "rt" option you get a compiler that is not able to use a libstdc++ optimisation normally enabled for single-threaded programs.
