From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id CAECA3954C7B; Thu, 17 Nov 2022 09:07:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CAECA3954C7B 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-ed1-x533.google.com with SMTP id z18so1586407edb.9; Thu, 17 Nov 2022 01:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lfjkDKIYSBEzczjfsfOs090Bdp88KFDfR0BtQj5mK/U=; b=loN/3uAyptYVukAdXlyYFX8PJwINt5fw5ZlSJNYpfsr0bESulL9NSxEboNyRJDY2BI oKuK4a7vOtwesVcewTpet6l+te1QBRZfD+C1ETxoH49oL4MyWXWCk3AKl3MwL2zycCgM ClvNbkxZrnhK0Lhu6WU+dnEaXINHDcweuGXfMuFaNn5mjhkmVzIA1TjDkBCQUWcCCa+Q DnNwDGNsCl0vqUrKYyB2BaPmy2Ffa2Rq6KYDjRivgYnPiPghKt7Pqj5DRJkdOOMi2GKX Rey07W3KHAyQecVAp1SBO0mUT+JfBGgpaYRLG8ffi8Eaj/dEfOVgubjQLUyGlz0beJRd Whng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=lfjkDKIYSBEzczjfsfOs090Bdp88KFDfR0BtQj5mK/U=; b=sh/ckg8H0hsO8NB1MjRhuejqopvky8e7oFMtQ/aLK5IOQbqj8IquEO8DGvMz2e4FGo salCPusGrHqVjq8p7xwhdPiFQlvKUL8AlLw7kKdh+rZEZsYYiSi9zY2jk7viSJw4+doX U1SG16/tXNqWxqQX4zBB8rTFETAWoA86fzbRB2TotE/MbwFwmpURkRuVdHHFVTFBGvuR cTEBlVWdYjDm6GqbZHxbSDuHwSWEtm74wH0X768oc8a/sQKfOc52HL8rJ5Kbl55qi2iW AzCw7zLiKesyVN0E8CG6NErTGcspmF6fvmJktgPF9DjSFTZqs4GgUaCXUHyJ6iLTyo8H 0oxw== X-Gm-Message-State: ANoB5plKM8QGSIBIAZRQsEruzV9ZjZLqtCIm2Sw42uKfUWF2EsqhO+97 pducLWPfbXVG4MFOp6ylqX/bCYeUEa3zCiedqMY= X-Google-Smtp-Source: AA0mqf5cA+mnkQ7UwApJDc5TonflkkxakLjlRiKIqHFnsYhd5bDUXM1+nyKx0IWhVWUULn3Mie+DFTVIe/i9NBVIEzM= X-Received: by 2002:a05:6402:1516:b0:467:7519:6bff with SMTP id f22-20020a056402151600b0046775196bffmr1326748edw.301.1668676042562; Thu, 17 Nov 2022 01:07:22 -0800 (PST) MIME-Version: 1.0 References: <20221116210014.1420128-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 17 Nov 2022 09:07:11 +0000 Message-ID: Subject: Re: [committed] libstdc++: Improve performance of chrono::utc_clock::now() To: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= Cc: Jonathan Wakely , "libstdc++" , gcc-patches Content-Type: multipart/alternative; boundary="000000000000c31d6605eda6ea3b" X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,HTML_MESSAGE,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: --000000000000c31d6605eda6ea3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 17 Nov 2022, 06:30 Daniel Kr=C3=BCgler via Libstdc++, < libstdc++@gcc.gnu.org> 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 recent > > leap second. On one system where I tested this, utc_clock::now() now > > 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/include/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 leaps > 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-28 > 00:00:00 UTC > > + const seconds::rep __expires =3D 1687910400; > > + const seconds::rep __s =3D __ut.time_since_epoch().count(); > > > > - auto __s =3D __ut.time_since_epoch().count(); > > - auto __pos =3D std::upper_bound(__leaps.begin(), > __leaps.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 seems > 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 partial merge from a local branch with the TODO fixed. Yes, it's inconsistent, but it works correctly and it's not my priority right now :-) --000000000000c31d6605eda6ea3b--