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 EB538396E07D for ; Thu, 17 Nov 2022 09:48:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB538396E07D 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=1668678524; 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=UoaJsU4RhYABS4+V6iClxxr99LfyS0vtlk05Wo1CLT0=; b=JfUR4MLaP5yhQ74RUvllDelzd1np8a31tABUb1aZT1fgu83f2hdbbUGNUPhDWrp3gbCY25 rEfuZsfHQ4Fm05kxe0chGvhVfRajnmPXuzcxykajpIOLX1RycpAmLIJFwMcisn0QoXigIR HCV0gaINkqZ/ZCMjCqYnbiRRfcRtBqo= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-452-5ndsx-JHPV-u-JPFZzEPbQ-1; Thu, 17 Nov 2022 04:48:40 -0500 X-MC-Unique: 5ndsx-JHPV-u-JPFZzEPbQ-1 Received: by mail-ej1-f69.google.com with SMTP id nb1-20020a1709071c8100b007ae4083d6f5so807683ejc.15 for ; Thu, 17 Nov 2022 01:48:40 -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=UoaJsU4RhYABS4+V6iClxxr99LfyS0vtlk05Wo1CLT0=; b=ckoTxsMuH/ArI/vG+Ii2C1d4I5vnxbz/1xZjEdfLuNc0ituw3IaNVYqjuQdBoZM3pp dLbZSUD8vpiZZP1bJEh6pHMPUSHbh2j0uOdag7wqYxAcWcZ5IRl7N5WTSWm4gDojAkEO rpmvUV51rEQ3YKEG8cZD16VaXcCfxyzRsqTv30egqgPxe7LyDaXHiEOnS3s+XgRV2iwf /A096upUt3pFpcOAKHITcIM8eql7GODDJxP8s/JdD9PO+dNZpTJvf2znmjobU2ijIs8K 34ixWg1cBUes5p1Dnv4ymGt6yhOM3mh3ww9e53BtDb1mtQnVK1LeYYH1bOO1lQrA0r/S NdSA== X-Gm-Message-State: ANoB5pm+flAnm1AO/mpUYi1ACj0w9wsuAuz6KwUvyJOZYW3HDPGGaFO3 C7GN83VHWwSDTcivSGGyqnvr5cqhp1++MP9zTtKAq35XGoXPCZeU3XaFBqSU7k5ivsjXaoWHSDj qSiy+DnEcUz9+j1fB4N5NPrHOtl2uWesNVw== X-Received: by 2002:aa7:dd04:0:b0:457:d794:f5ee with SMTP id i4-20020aa7dd04000000b00457d794f5eemr1473990edv.227.1668678519593; Thu, 17 Nov 2022 01:48:39 -0800 (PST) X-Google-Smtp-Source: AA0mqf4IJzQcpQzFulGSQxZOJzgFL40RddJKdQ/AIuEwBsKGwmpRGSKqmoTZUVPQIjkp5FYBxLIrn4dq7hwFwopwFeE= X-Received: by 2002:aa7:dd04:0:b0:457:d794:f5ee with SMTP id i4-20020aa7dd04000000b00457d794f5eemr1473983edv.227.1668678519465; Thu, 17 Nov 2022 01:48:39 -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:48:28 +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="00000000000065ba6805eda77eb7" X-Spam-Status: No, score=-12.7 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=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000065ba6805eda77eb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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().coun= t(); >> >> > >> >> > - 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, b= ut >> 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? --00000000000065ba6805eda77eb7--