std::chrono is much slower than native requests...?

[Jonathan Wakely]

On Sun, 7 Jul 2019 at 21:18, Paul Smith <psmith@gnu.org> 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.