From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7A28239730DB for ; Thu, 17 Nov 2022 10:31:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A28239730DB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668681076; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1N2RSyKlQx3KLeYXPezJK9K28KuLoRIV5hiAYgheLoc=; b=foiNWZpgdUWRv+/By49t3mkZ6V3MhK/Lg2UxeMMEIGunfbStAOykK+hU53SDefJhfAriX0 AB7oPvg6YXRolcLXJZc4b090yI2MXNWqsg3wRnA8+WjekAu7giJuF6ro2zwE+ugHDZjY0C Q61oM9e6tMGRpLcMwNOrnPQ6Yv3QPiw= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-224-jpXYAyvCOvSZtRcTtep6qg-1; Thu, 17 Nov 2022 05:31:11 -0500 X-MC-Unique: jpXYAyvCOvSZtRcTtep6qg-1 Received: by mail-ed1-f70.google.com with SMTP id h9-20020a05640250c900b00461d8ee12e2so936929edb.23 for ; Thu, 17 Nov 2022 02:31:11 -0800 (PST) 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=1N2RSyKlQx3KLeYXPezJK9K28KuLoRIV5hiAYgheLoc=; b=XqlQ6qMYsx9jPB9ESE5y5Sz6vDV8gaH3x439LNJWiYqpqZncGymeCAwMx/j44KA1i1 5y+BCmwYstYYmseUt/kxpZDlY+H+z56cspzYmXK8eZAakQC7Q5KJ3jqfi4PVnZlL9N8H SAsA8mGpeLiXh650DVKPDtCuPSlRFRS9o2haQmuZfN2FN5Wfw6IzwTh7GJ0r5E49ddxb syuCFa0ikboLScfnLNu8CXSDuaPMlwIcCQLpBfm4Sk5sXA/kwxXolHC4eiXkxa9d4l3g IWdoYqsAtVcz/5xuFGBEN1QGVZfRr9BjJsZ/qUdMotXvXhYiVXgkhkdgRqLnWWyCrTWi Bwdg== X-Gm-Message-State: ANoB5pkKcOrgCbhwQQd2veL76yhzQlxZAZ1sKi6NOLrrkFPvA0yFIjff AUBJjANEEXVIcQ3QV5s1Zbp8tpk0/Bzo3Ycc7bIAoR3jTHp8U+pyBYOnqRw8sX3D7f6WVX5v3z8 2fuoMa6yiBOa5K8c5Ix+1eOznTtwZlAw= X-Received: by 2002:a05:6402:5487:b0:468:816f:bbc9 with SMTP id fg7-20020a056402548700b00468816fbbc9mr1541114edb.78.1668681070585; Thu, 17 Nov 2022 02:31:10 -0800 (PST) X-Google-Smtp-Source: AA0mqf7FG1k90G93nzBFqpIvEs18vuQGIf7VokVdj10lRSX93FJOgdgGkqZGxfYJvNmtMQ9vKCtokX8AvPliczc6nng= X-Received: by 2002:a05:6402:5487:b0:468:816f:bbc9 with SMTP id fg7-20020a056402548700b00468816fbbc9mr1541098edb.78.1668681070347; Thu, 17 Nov 2022 02:31:10 -0800 (PST) MIME-Version: 1.0 References: <20221116210014.1420128-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 17 Nov 2022 10:30:59 +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 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000071182905eda816b2" X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: --00000000000071182905eda816b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 17 Nov 2022 at 09:57, Daniel Kr=C3=BCgler wrote: > Am Do., 17. Nov. 2022 um 10:48 Uhr schrieb Jonathan Wakely < > jwakely@redhat.com>: > > > > > > > > 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++, < > 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 t= he > >>> >> > 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 := -) > >>> > >>> 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. > > It is useful and I do appreciate the review, but like I said, the code is going to change soon anyway, so I don't see any point making tiny stylistic changes now (there's no problem with ADL here, as the array contains int64_t values, and calling begin on an array is cheap). This is what I have in my local branch: template leap_second_info get_leap_second_info(const utc_time<_Duration>& __ut) { if (__ut < utc_time<_Duration>{}) [[unlikely]] return {}; if constexpr (is_same_v<_Duration, seconds>) { const seconds::rep __leaps[] { 78796800, // 1 Jul 1972 94694400, // 1 Jan 1973 126230400, // 1 Jan 1974 157766400, // 1 Jan 1975 189302400, // 1 Jan 1976 220924800, // 1 Jan 1977 252460800, // 1 Jan 1978 283996800, // 1 Jan 1979 315532800, // 1 Jan 1980 362793600, // 1 Jul 1981 394329600, // 1 Jul 1982 425865600, // 1 Jul 1983 489024000, // 1 Jul 1985 567993600, // 1 Jan 1988 631152000, // 1 Jan 1990 662688000, // 1 Jan 1991 709948800, // 1 Jul 1992 741484800, // 1 Jul 1993 773020800, // 1 Jul 1994 820454400, // 1 Jan 1996 867715200, // 1 Jul 1997 915148800, // 1 Jan 1999 1136073600, // 1 Jan 2006 1230768000, // 1 Jan 2009 1341100800, // 1 Jul 2012 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(); if (__s < __expires) { const seconds::rep* __first =3D std::begin(__leaps); const seconds::rep* __last =3D std::end(__leaps); // 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 __first && __pos[-1] =3D=3D __s, seconds{__pos - __first} }; } else { // use updated leap_seconds from tzdb auto __db =3D get_tzdb_list().begin(); auto __first =3D __db->leap_seconds.begin(); auto __last =3D __db->leap_seconds.end(); sys_seconds __ss(__ut.time_since_epoch()); auto __pos =3D std::upper_bound(__first, __last, __ss); return { __pos !=3D __first && __pos[-1] =3D=3D __ss, seconds{__pos - __first} }; } } else { auto __s =3D chrono::time_point_cast(__ut); return chrono::get_leap_second_info(__s); } } But that can't be pushed to trunk now because get_tzdb_list() isn't defined on trunk yet. If you have any comments about *this* version, I'll be happy to hear them :-) --00000000000071182905eda816b2--