From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17163 invoked by alias); 8 Jul 2019 12:20:03 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 17150 invoked by uid 89); 8 Jul 2019 12:20:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BL autolearn=no version=3.3.1 spammy=H*M:online, H*r:encrypted, pay, H*r:sk:mailout X-HELO: mailout06.t-online.de Received: from mailout06.t-online.de (HELO mailout06.t-online.de) (194.25.134.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jul 2019 12:20:01 +0000 Received: from fwd18.aul.t-online.de (fwd18.aul.t-online.de [172.20.26.244]) by mailout06.t-online.de (Postfix) with SMTP id 9EB09419B3B8; Mon, 8 Jul 2019 14:19:57 +0200 (CEST) Received: from yam-desktop (VytMdaZOgh+mrLBA2QyfK+PF+7Gneb71gWRc0LclDj2ahoOKv70zs+2b-gNj+PmQxd@[163.58.16.102]) by fwd18.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1hkScc-16Y7ua0; Mon, 8 Jul 2019 14:19:54 +0200 Message-ID: Subject: Re: std::chrono is much slower than native requests...? From: Oleg Endo To: Jonathan Wakely , Paul Smith Cc: "gcc-help@gcc.gnu.org" Date: Mon, 08 Jul 2019 12:20:00 -0000 In-Reply-To: References: <6eff7f25b45483b542e671b18dfe44b5f4c1b517.camel@gnu.org> <5f74b98325ef97b4913e87d1d8774440d85d3e32.camel@gnu.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00090.txt.bz2 On Sun, 2019-07-07 at 22:00 +0100, Jonathan Wakely wrote: > On Sun, 7 Jul 2019 at 21:18, Paul Smith 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