From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id AADAD382FCA8; Thu, 17 Nov 2022 06:30:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AADAD382FCA8 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-pj1-x1036.google.com with SMTP id b11so810637pjp.2; Wed, 16 Nov 2022 22:30:00 -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=Lg8zHWh3xNw8ihjoqAw/z2WtWiOsBm/rjiiI4brbvP4=; b=Af5wvA94c05ShKiUjEDA+EQWT0EaoGQ8Px6KfApQY+vZyJ3jGr9QZdd9cT2tJ+OyoJ WK9V+KbaiSP8enlo4ql+pE8d5FxCb4ECw7lshR3BlssyGwvstNluD49ltwMb046dqlrT oySQx21TPhJSPAxJJdB56mPj+NbLw48tWu17E5uXfqc6O8vIjxOxzfUmSTWyEHRYlV8X Fk27RL4EXhiZzG+bwXTVeW13KR2Pqmr8UU7mtbEEeWkYSXR9Yi49+Od6pAFONbu1x3EW 44XKmc3rUE4gBEjqRnyA/GApsNtkp9kGPOcvs9SnPyaFeiqocSxwjb/aFjqCyRKQlqHs ypIQ== 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=Lg8zHWh3xNw8ihjoqAw/z2WtWiOsBm/rjiiI4brbvP4=; b=6nTeySB39qK65RZuZw1/+GyZ3stpWxU5NePVqUf3Idw4iNO81+xuMD1hFQCxjo8Lxn p+HFADQ3Zbp0uMCMwSly7rbyQLs3++wUxbsgwXFuff0fbScVxmypTSFav6g2Zi+l1paz 7wfWkQsowagR7HgiH5IVeujKsbuv7BR7qpnPfrFshM4phgTtf7ZkU0J9YA2TmNFgfhl3 jkV1aIwMuTNUWUAm29pNKHMHZ7QgrXkLsQR1Jdw0nDbJoEtSXFF0H8QB1Fnn4mDoC9v8 nITPgk33krWZeH0Wce3dR6rjWIDv8/Dt2+WSx3Jn6Niug9WXR2e2q8LxrWme3HRnN6j6 RZjQ== X-Gm-Message-State: ANoB5pnhWCXLxgQpy0xP7Z4QI7XF/kkGA7zYJ2J+sVgz5vNSJmOzuPY/ S7sByHArn0N4nsfuB9v3b6uJG9CdulzUNYZnRvQ= X-Google-Smtp-Source: AA0mqf6GXkxzed3LCeSZnODHvbx2eyD+Lu3mbj1KuwW8ZDBmD47fc0rvDJ3SiGDAfFg/SavZNQUFN0MG2Eqy31kZuVE= X-Received: by 2002:a17:902:d58d:b0:186:8af2:8bc8 with SMTP id k13-20020a170902d58d00b001868af28bc8mr1320625plh.146.1668666599551; Wed, 16 Nov 2022 22:29:59 -0800 (PST) MIME-Version: 1.0 References: <20221116210014.1420128-1-jwakely@redhat.com> In-Reply-To: <20221116210014.1420128-1-jwakely@redhat.com> From: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= Date: Thu, 17 Nov 2022 07:29:48 +0100 Message-ID: Subject: Re: [committed] libstdc++: Improve performance of chrono::utc_clock::now() To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 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 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 = 1687910400; > + const seconds::rep __s = __ut.time_since_epoch().count(); > > - auto __s = __ut.time_since_epoch().count(); > - auto __pos = std::upper_bound(__leaps.begin(), __leaps.end(), __s); > + const seconds::rep* __first = std::begin(__leaps); > + const seconds::rep* __last = std::end(__leaps); > + > + if (__s > __expires) > + { > + // TODO: use updated leap_seconds from tzdb > +#if 0 > + auto __db = get_tzdb_list().begin(); > + __first = __db->leap_seconds.data(); > + __last = __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 = std::upper_bound(__first, __last, __s); > return { > - __pos != __leaps.begin() && __pos[-1] == __s, > - seconds{__pos - __leaps.begin()} > + __pos != begin(__leaps) && __pos[-1] == __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. - Daniel