From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) by sourceware.org (Postfix) with ESMTPS id 341B03858D28 for ; Thu, 31 Aug 2023 13:47:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 341B03858D28 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-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-7a2c1ae77b3so250471241.2 for ; Thu, 31 Aug 2023 06:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1693489663; x=1694094463; 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=0xPG2STd8Q50gYAJjyIUzERZXdv4XKITvp0/XxX8nk4=; b=jOzh4VQbkudw868w86ZD8q98gxnu8MMqryQOt+iKNaYf9TfSYSOQVPLpO6IVuM3/Yg FRCDge04UuL4v/TIVB5iudgJ5EsSMDOGhgwk4GwVzFmhlai9qx/Yj6vmjsQUDXPJY3PY aulAWQDT3Z3yWxpPo2MkqqrZKJc0u1PFmtQqg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693489663; x=1694094463; 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=0xPG2STd8Q50gYAJjyIUzERZXdv4XKITvp0/XxX8nk4=; b=hQJXabE6uMu+FrlK3EYYlVyi8tX/GeT6Cqr9EO6RAA1R68Dm8hPD8V5PHVsdL2JmS/ oz4HuFPkL/x7u7MMt5j5O2bE8k9drupu9l2nrSEmNItHcJto6rHVvLC0VcXGkxDQQRC+ yJJKsUhWYTC6a/PhqHJIH3M4qtaCrV+U5Ep3Aw41/0T3iaXJ4bbz0O/wLp95eF6y0efH gTomjYwNK5oyPIxGInX7EXQJmZ0CGRnL7XkmYamOlMxkGaoOVphAWtzaqrH6w7G4epcc jT+ueftKCau0Zn2rwver8bjRj88xSTmShNv6DTVUlU+vOO4DFjUju2hzqBZ+QlbxbJEi gskg== X-Gm-Message-State: AOJu0YxeawBMc2omJzcheu2Enbi+jG+aOqx35n8Lvps1h5d6kY9PGQbW whdqq8YaPNuQfsRucRIKskOo+i6Gq+Fg9Yrio8o4MQ== X-Google-Smtp-Source: AGHT+IHOCPvubmpakWduaBtrvUHvMQIC2HXdYKA+7eVtTuMv9Xs26r/84Y3qX2Bee3K+Lee+PtUzD3Te+ErJDqa+Ljk= X-Received: by 2002:a67:f810:0:b0:44e:8353:e86a with SMTP id l16-20020a67f810000000b0044e8353e86amr4456451vso.24.1693489662946; Thu, 31 Aug 2023 06:47:42 -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 06:47:27 -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=-12.8 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 Tue, Aug 8, 2023 at 1:14=E2=80=AFPM Jonathan Wakely = wrote: > > > > On Tue, 18 Jul 2023 at 07:28, Ken Matsui via Libstdc++ wrote: >> >> I will eventually work on disjunction to somehow optimize, but in the >> meantime, this might be a better implementation. Of course, my >> benchmark could be wrong. > > > You should use __or_ internally in libstdc++ code, not std::disjunction. > > Patrick already optimized both of those, and __or_ is slightly faster (be= cause it doesn't have to conform to the full requirements of std::disjuncti= on). > I will! Thank you! > A compiler built-in for __or_ / __disjunction might perform better. But e= ventually if we're going to have built-ins for all of __is_arithmetic, __is= _void, and __is_null_pointer, then we would want simply: > > __is_arithmetic(T) || __is_void(T) || __is_null_pointer(T) > > and so we wouldn't need to avoid instantiating any class templates at all= . > I think we are not going to define built-ins for is_void and is_null_pointer as their type trait implementations are already optimal. > >> >> >> On Mon, Jul 17, 2023 at 11:24=E2=80=AFPM Ken Matsui 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% >> > >> > 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. >>