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

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

 



On Sun, 7 Jul 2019 at 22:00, 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.

How's this?

--- a/libstdc++-v3/doc/xml/manual/configure.xml
+++ b/libstdc++-v3/doc/xml/manual/configure.xml
@@ -166,18 +166,24 @@

  <varlistentry><term><code>--enable-libstdcxx-time=OPTION</code></term>
  <listitem><para>Enables link-type checks for the availability of the
-       clock_gettime clocks, used in the implementation of [time.clock],
-       and of the nanosleep and sched_yield functions, used in the
+       <function>clock_gettime</function> clocks, used in the implementation
+       of [time.clock], and of the <function>nanosleep</function> and
+       <function>sched_yield</function> functions, used in the
        implementation of [thread.thread.this] of the 2011 ISO C++ standard.
        The choice OPTION=yes checks for the availability of the facilities
        in libc and libposix4.  In case it's needed the latter is also linked
-       to libstdc++ as part of the build process.  OPTION=rt also searches
-       (and, if needed, links) librt.   Note that the latter is not always
-       desirable because, in glibc, for example, in turn it triggers the
-       linking of libpthread too, which activates locking, a large overhead
-       for single-thread programs.  OPTION=no skips the tests completely.
+       to libstdc++ as part of the build process.  OPTION=rt also checks in
+       librt (and, if it's needed, links to it).  Note that linking to librt
+       is not always desirable because for glibc it requires linking to
+       libpthread too, which causes all reference counting to use atomic
+       operations, resulting in a potentially large overhead for
+       single-threaded programs.  OPTION=no skips the tests completely.
        The default is OPTION=auto, which skips the checks and enables the
        features only for targets known to support them.
+       For Linux targets, if <function>clock_gettime</function> is not used
+       then the [time.clock] implementation will use a system call to access
+       the realtime and monotonic clocks, which is significantly slower than
+       the C library's <function>clock_gettime</function> function.
     </para>
  </listitem></varlistentry>





> > 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.



[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