From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by sourceware.org (Postfix) with ESMTPS id 7FD3A3858D28 for ; Thu, 31 Aug 2023 15:01:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7FD3A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.washington.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.washington.edu Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-76dbe263c68so38514985a.0 for ; Thu, 31 Aug 2023 08:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1693494105; x=1694098905; darn=gcc.gnu.org; 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=LkykAmIFB/7HS+ElyXXTjRcrJk1PMteVD9nXaootfM8=; b=TYtjYss8KqJI0ihX031Jw+qhjsg1TZCW7aipOnWNJlZPY6bN3Dd7ZvepW+7iOLJiN0 1T5gZjNl/M6ZoHwaaU8AvsAseL7DQeylFkhFyXNt5+8L3gu01dUjSj/n4dSowk4ZGub/ 0pNqt4poW5grEfJk+Fg78/XL+wRxoNrur60JQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693494105; x=1694098905; 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=LkykAmIFB/7HS+ElyXXTjRcrJk1PMteVD9nXaootfM8=; b=ACNsXtfqcmJ4Uw15SZSvjPmzzDhcFKL8B9qy6sq3FHAp81hdssnYW7XKrsnXJvCckV rQweU/J7hdLxfqcZBcAFuIsmbnc0Zkcf5G8y7US5isrZq9q67T655DnC6eQ0EkFuw01K 3nhTfeL4vQ7vzCALnakRJhaH+9meaaDFjVVSqFrhZw3lClHioZoPbg0stmQveuezTYLF aPnoqY6GWmst+f8P+izpG15/Zjm3wOja6w4Qg1OUehLCDgwugpCZy7pteOz61g0M4L5x 1uwXBGU7oCVudef+E4rigZ6y6fev7m1Bezr9xV23HE6goKXpqsOwDMIy6ZFU/F8DVNtK RTvQ== X-Gm-Message-State: AOJu0YzTZQ06u4KPiPR28bOtec58oimeGZyGfZCqcVKX4onGCllZZmZ8 DNM1QvLZ20128XVBkuciOiUWF7LgEDpZWqsK69mVeA== X-Google-Smtp-Source: AGHT+IFCN8+hfAZ2DJ2/XOBF0qnFJsH4TujaL1+lx0o3vEy7x26P1GgykcbbLV2sCRJcG36QGXOANo+5fCu3ICE5WEg= X-Received: by 2002:a05:620a:2407:b0:76e:ea58:3c2 with SMTP id d7-20020a05620a240700b0076eea5803c2mr3859804qkn.33.1693494104651; Thu, 31 Aug 2023 08:01:44 -0700 (PDT) MIME-Version: 1.0 References: <20230709125715.26884-1-kmatsui@gcc.gnu.org> <20230715045519.50684-1-kmatsui@gcc.gnu.org> <20230715045519.50684-3-kmatsui@gcc.gnu.org> <3aa7cf30-27f1-7e69-7334-fc9918928f90@gmail.com> In-Reply-To: From: Ken Matsui Date: Thu, 31 Aug 2023 08:01:08 -0700 Message-ID: Subject: Re: [PATCH v2 3/3] libstdc++: Optimize is_fundamental performance by __is_arithmetic built-in To: Jonathan Wakely Cc: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= , Ken Matsui , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On Thu, Aug 31, 2023 at 6:57=E2=80=AFAM Ken Matsui wrote: > > On Tue, Aug 8, 2023 at 1:19=E2=80=AFPM Jonathan Wakely wrote: > > > > > > > > On Tue, 18 Jul 2023 at 07:25, Ken Matsui via Libstdc++ wrote: > >> > >> Hi, > >> > >> I took a benchmark for this. > >> > >> https://github.com/ken-matsui/gcc-benches/blob/main/is_fundamental-dis= junction.md#mon-jul-17-105937-pm-pdt-2023 > >> > >> template > >> struct is_fundamental > >> : public std::bool_constant<__is_arithmetic(_Tp) > >> || std::is_void<_Tp>::value > >> || std::is_null_pointer<_Tp>::value> > >> { }; > >> > >> is faster than: > >> > >> template > >> struct is_fundamental > >> : public std::bool_constant<__is_arithmetic(_Tp) > >> || std::disjunction, > >> std::is_null_pointer<_= Tp> > >> >::value> > >> { }; > >> > >> Time: -32.2871% > >> Peak Memory: -18.5071% > >> Total Memory: -20.1991% > > > > > > But what about the fallback implementation of is_fundamental where we d= on't have the __is_arithmetic built-in? > > That fallback implementation would be this: > https://github.com/ken-matsui/gsoc23/blob/967e20770599f2a8925c9794669111f= aef11beb7/is_fundamental.cc#L11-L15. > > The is_fundamental-disjunction.cc benchmark used the USE_BUILTIN > macro, but in this benchmark, I used it to just switch two different > implementations that use the __is_arithmetic built-in. > > > - : public __or_, is_void<_Tp>, > > - is_null_pointer<_Tp>>::type > > + : public __bool_constant::value > > + || is_void<_Tp>::value > > + || is_null_pointer<_Tp>::value> > > > > Here the use of __or_ means that for is_fundamental we don't insta= ntiate is_void and is_null_pointer. Isn't that still worthwhile? > > > Let me take a benchmark with __or_ later! We may see a difference. > Here is the benchmark result with __or_: https://github.com/ken-matsui/gsoc23/blob/main/is_fundamental-disjunction.m= d#thu-aug-31-075127-am-pdt-2023 Time: -23.3935% Peak Memory: -10.2915% Total Memory: -14.4165% Considering the following was with disjunction, __or_ is faster than disjunction, but still just || seems much faster. Time: -32.2871% Peak Memory: -18.5071% Total Memory: -20.1991% > > > > > > > >> > >> > >> Sincerely, > >> Ken Matsui > >> > >> On Sun, Jul 16, 2023 at 9:49=E2=80=AFPM Ken Matsui wrote: > >> > > >> > On Sun, Jul 16, 2023 at 5:41=E2=80=AFAM Fran=C3=A7ois Dumont wrote: > >> > > > >> > > > >> > > On 15/07/2023 06:55, Ken Matsui via Libstdc++ wrote: > >> > > > This patch optimizes the performance of the is_fundamental trait= by > >> > > > dispatching to the new __is_arithmetic built-in trait. > >> > > > > >> > > > libstdc++-v3/ChangeLog: > >> > > > > >> > > > * include/std/type_traits (is_fundamental_v): Use __is_ari= thmetic > >> > > > built-in trait. > >> > > > (is_fundamental): Likewise. Optimize the original implemen= tation. > >> > > > > >> > > > Signed-off-by: Ken Matsui > >> > > > --- > >> > > > libstdc++-v3/include/std/type_traits | 21 +++++++++++++++++---= - > >> > > > 1 file changed, 17 insertions(+), 4 deletions(-) > >> > > > > >> > > > diff --git a/libstdc++-v3/include/std/type_traits b/libstdc++-v3= /include/std/type_traits > >> > > > index 7ebbe04c77b..cf24de2fcac 100644 > >> > > > --- a/libstdc++-v3/include/std/type_traits > >> > > > +++ b/libstdc++-v3/include/std/type_traits > >> > > > @@ -668,11 +668,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > >> > > > #endif > >> > > > > >> > > > /// is_fundamental > >> > > > +#if __has_builtin(__is_arithmetic) > >> > > > + template > >> > > > + struct is_fundamental > >> > > > + : public __bool_constant<__is_arithmetic(_Tp) > >> > > > + || is_void<_Tp>::value > >> > > > + || is_null_pointer<_Tp>::value> > >> > > > + { }; > >> > > > >> > > What about doing this ? > >> > > > >> > > template > >> > > struct is_fundamental > >> > > : public __bool_constant<__is_arithmetic(_Tp) > >> > > || __or_, > >> > > is_null_pointer<_Tp>>::value= > > >> > > { }; > >> > > > >> > > Based on your benches it seems that builtin __is_arithmetic is muc= h better that std::is_arithmetic. But __or_ could still avoid instantiation= of is_null_pointer. > >> > > > >> > Let me take a benchmark for this later. > >>