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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 8 Jul 2019 at 13:19, Oleg Endo <oleg.endo@xxxxxxxxxxx> wrote:
>
> 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.

What do you base that expectation on? Only accesses to
std::sig_atomic_t variables are safe in signal handlers.

>  But if all it takes is linking in pthread, that's no
> problem.

It's orthogonal to this discussion anyway. The
--enable-libstdcxx-time=rt option can cause all ref counting to be
atomic, which isn't going to make the signal handler case any worse.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux