From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 2555B3835780; Thu, 17 Nov 2022 09:25:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2555B3835780 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-pl1-x62a.google.com with SMTP id p21so1075497plr.7; Thu, 17 Nov 2022 01:25:39 -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=kU2L4/Tk3in686Fjic1qGEf8O5ZMdB3UHQfHJOqQaKE=; b=LIwSt3c5cnVGKwsHEfHtwuXgeABCwR5p+YGQoROuvaUKzLOwvwWF+xqf/JN4h1t0b0 bz7oHOSj3sY+SmJ0Ul2xxb662rF2mJber3thKBfcqqih3Q05cA0Wb9LQbdWfV73w7cUf 8m0l2pM2hSXZfR89K1eewsZ3m5HJZJwJvdbLUKPsbOXQL4e39vLaEBzh0jFoh+KwZL3N EOExW4QT1txGHDZP4doedzh0I9sLDSfkAN3NNWkIliLCqd75FqdMObOfcdIgRskhX2km cY9pjdVVgZVabMA3R5/rT9WVBescr7gTEdgOvoV7EgpzpZY9DiD3bcP8w3FTizleESIJ vMiA== 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=kU2L4/Tk3in686Fjic1qGEf8O5ZMdB3UHQfHJOqQaKE=; b=IXsETnJvLnvZt8KA8cxYK/88uT1RbBFqrRAo5qd7f1Y7eTxjohHzxZDLAuk+HY+00a 5pzNsXgAK2tjhYdVjeOypbhicM5xXCFzYb3M5xauFvaRBWZWnVwL387zn56pO/xomLCk Df3TmK4N5L6Oh6oeuuWXND3xd8hegCZLZ9Z8753dvyNLbN3HhZ3593XfFI231OHkuHMX bRKyZ77OtIgXjP7p4ChqFNWMNwqc0kug7/KObXN60fYsAyaMo19qrTkGcR0vFgY1wyyF m6sYphGZpIbweUB+ZwshsNfxYPcLO8hKIri+SoPY45h+nzR7QckWjB2iITjh/2GkkXqo 7HMA== X-Gm-Message-State: ANoB5pkF5PpIGZ2+a67h8aD0l+X3Yl8+kXgJ33wzgQv3LAwXAby8NWKa LxBsW3jyhRgtK0j3b8w4sKvqXO+BhOgREclSLzs= X-Google-Smtp-Source: AA0mqf4bpOZnf/ofqbHNXZBO75qn2BQpxUvHeOKPN4V2obzzdd9B8poGLsfXwD4hC1WuJhpg703Jp6CNY9IUebkkyPg= X-Received: by 2002:a17:902:d58d:b0:186:8af2:8bc8 with SMTP id k13-20020a170902d58d00b001868af28bc8mr1834358plh.146.1668677138041; Thu, 17 Nov 2022 01:25:38 -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:25:26 +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=-7.6 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: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 recen= t >> > 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/st= d/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.e= nd(), __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 me= rge from a local branch with the TODO fixed. Yes, it's inconsistent, but 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? Thanks, - Daniel