From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id AC342395C034; Thu, 17 Nov 2022 09:56:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AC342395C034 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x533.google.com with SMTP id 136so1554387pga.1; Thu, 17 Nov 2022 01:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HAoinivBj80EHWgB+1z8RHe2N/rVHIZuA4l2eKno4SU=; b=dHpPX2OqxshLUE7k2xXPyMTZlT7WwhbzPoCA7AMaAbPVLQ7MRTdsO9fyxEU644n2QU +nYQOTN0XvRxDdrE9Hfrf4KFXj617srbtDEPCpJSG1/L1KgO9yJ+U6V3n5P8V6jbr68d slSnTII3v2qvvq3j0nQB40GUJ17ccWvKa37kJs0mhn1VyLn9J+s0z/Hvb1TR3Tmv3U9A Co7D/fIdSX9SqgUcqLpBr1t/dJb0TAIGU5yKKO+e3VPd0KcZXLoeymBPXbpY/89cBAdm 8wA3fdsI1c+8OozsjvmUEB1gJI8/5C/VWiuACYzeq+7nxJPbF7dJ3QhTEDghCuCdkvki 3Mjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HAoinivBj80EHWgB+1z8RHe2N/rVHIZuA4l2eKno4SU=; b=BXdNmnawS7/V5H66ayKNR2v/RJ1oUhJHy7vDbNOAy6etz/IIXn9Y06uRaRjyKWWgny PK3F1pYeeVUHBJVknVBuYVxvUSQP4jgf9PNVjtO/IWNabmzSOo4JY55QBvWZhTdID71F erAR8ZKnCZQcWvOZVFKmh2VgDYRLyneZiQgp5OdCerJtlrgEyWhQmEYTAqrLQawOI5mE 3HwIXZKuYm8tXDAAv6JLyqRgyfhVBklitBgw1tdphIO24iB+wFb3HVEuH6IG+2BWOxAV /RFy06bqlJVP4wvFoDJhI1HRKCljy3Jn/tF4p2lLKx+JYCph98uM/9pOkwf8/Og2vvmZ sx2g== X-Gm-Message-State: ANoB5plo6x07DyJbIfO1sAGc4LKQLh4VSWR1AW6LjNsXZ8yc02nN09+b eaqR/ri5jPJpKQNG4mEfM8zrY08I63fvdPGDEQw= X-Google-Smtp-Source: AA0mqf42Wzb6PN3ceVHazxON1+S5pIQkt+8frfy7OL11IxXmL/In6BLTXHArJqMPyf8gUpCqbiBaq/xkptRA/D1lejU= X-Received: by 2002:a65:588b:0:b0:456:f7bd:a1 with SMTP id d11-20020a65588b000000b00456f7bd00a1mr1410520pgu.79.1668679016690; Thu, 17 Nov 2022 01:56:56 -0800 (PST) MIME-Version: 1.0 References: <20221116210014.1420128-1-jwakely@redhat.com> In-Reply-To: From: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= Date: Thu, 17 Nov 2022 10:56:45 +0100 Message-ID: Subject: Re: [committed] libstdc++: Improve performance of chrono::utc_clock::now() To: Jonathan Wakely Cc: Jonathan Wakely , "libstdc++" , gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Do., 17. Nov. 2022 um 10:48 Uhr schrieb Jonathan Wakely : > > > > On Thu, 17 Nov 2022 at 09:47, Jonathan Wakely wrote: >> >> >> >> On Thu, 17 Nov 2022 at 09:25, Daniel Kr=C3=BCgler wrote: >>> >>> Am Do., 17. Nov. 2022 um 10:07 Uhr schrieb Jonathan Wakely >>> : >>> > >>> > >>> > >>> > On Thu, 17 Nov 2022, 06:30 Daniel Kr=C3=BCgler via Libstdc++, wrote: >>> >> >>> >> Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via >>> >> Libstdc++ : >>> >> > >>> >> > Tested x86_64-linux. Pushed to trunk. >>> >> > >>> >> > -- >8 -- >>> >> > >>> >> > We can use an array instead of a std::vector, and we can avoid the >>> >> > binary search for the common case of a time point after the most r= ecent >>> >> > leap second. On one system where I tested this, utc_clock::now() n= ow >>> >> > takes about 16ns instead of 31ns. >>> >> > >>> >> > libstdc++-v3/ChangeLog: >>> >> > >>> >> > * include/std/chrono (get_leap_second_info): Optimize. >>> >> > --- >>> >> > libstdc++-v3/include/std/chrono | 31 ++++++++++++++++++++++++----= --- >>> >> > 1 file changed, 24 insertions(+), 7 deletions(-) >>> >> > >>> >> > diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/includ= e/std/chrono >>> >> > index 90b73f8198e..2468023f6c5 100644 >>> >> > --- a/libstdc++-v3/include/std/chrono >>> >> > +++ b/libstdc++-v3/include/std/chrono >>> >> > @@ -2747,9 +2747,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >>> >> > { >>> >> > if constexpr (is_same_v<_Duration, seconds>) >>> >> > { >>> >> > - // TODO move this function into the library and get le= aps from tzdb. >>> >> > - vector __leaps >>> >> > - { >>> >> > + const seconds::rep __leaps[] { >>> >> > 78796800, // 1 Jul 1972 >>> >> > 94694400, // 1 Jan 1973 >>> >> > 126230400, // 1 Jan 1974 >>> >> > @@ -2778,12 +2776,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >>> >> > 1435708800, // 1 Jul 2015 >>> >> > 1483228800, // 1 Jan 2017 >>> >> > }; >>> >> > + // The list above is known to be valid until 2023-06-2= 8 00:00:00 UTC >>> >> > + const seconds::rep __expires =3D 1687910400; >>> >> > + const seconds::rep __s =3D __ut.time_since_epoch().cou= nt(); >>> >> > >>> >> > - auto __s =3D __ut.time_since_epoch().count(); >>> >> > - auto __pos =3D std::upper_bound(__leaps.begin(), __lea= ps.end(), __s); >>> >> > + const seconds::rep* __first =3D std::begin(__leaps); >>> >> > + const seconds::rep* __last =3D std::end(__leaps); >>> >> > + >>> >> > + if (__s > __expires) >>> >> > + { >>> >> > + // TODO: use updated leap_seconds from tzdb >>> >> > +#if 0 >>> >> > + auto __db =3D get_tzdb_list().begin(); >>> >> > + __first =3D __db->leap_seconds.data(); >>> >> > + __last =3D __first + __db->leap_seconds.size(); >>> >> > +#endif >>> >> > + } >>> >> > + >>> >> > + // Don't bother searching the list if we're after the = last one. >>> >> > + if (__s > __last[-1]) >>> >> > + return { false, seconds(__last - __first) }; >>> >> > + >>> >> > + auto __pos =3D std::upper_bound(__first, __last, __s); >>> >> > return { >>> >> > - __pos !=3D __leaps.begin() && __pos[-1] =3D=3D __s, >>> >> > - seconds{__pos - __leaps.begin()} >>> >> > + __pos !=3D begin(__leaps) && __pos[-1] =3D=3D __s, >>> >> >>> >> The inconsistency between usage of std::begin versus begin here seem= s >>> >> odd and I'm wondering why instead of "begin(__leaps)" the above >>> >> introduced "__first" variable is not used instead. >>> > >>> > >>> > Because this code is going to be changed again soon, this is a partia= l merge from a local branch with the TODO fixed. Yes, it's inconsistent, bu= t it works correctly and it's not my priority right now :-) >>> >>> What about the suggestion to use the already existing "__first" >>> variable instead of the begin call? >> >> >> It's an array, the begin call is free. > > Do you really want me to stop working on the missing time zone support to= test and commit that change? I do not. I was reviewing and hoping to make a useful comment. Thanks, - Daniel