On Sun, 2019-07-07 at 22:00 +0100, Jonathan Wakely wrote: > 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. Even with single-threaded programs there could be async signal handlers.... and on MCU/baremetal targets we've got interrupt handlers, which are conceptually the same. I'd expect shared_ptr to just work there, too. But if all it takes is linking in pthread, that's no problem. Cheers, Oleg
