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.129.124]) by sourceware.org (Postfix) with ESMTPS id 9ADAD3858D20 for ; Tue, 8 Aug 2023 20:14:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9ADAD3858D20 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=1691525687; 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=znyiJyK0+LqGR8XmS1U6TkGYktFtY45iVgfiwKJdAqk=; b=BA4fb3TUvqDup5xjN7s7xeiOxCBwuNCkKxbT34LHeYoxXYZDJ61CWgpd4F/pQefM37pLKX f3unmXqa0LufC0PS/RkGrNUPXNlPeta3/ttAqx0hc/3l5EdUyhgBo6ItTA2bFW3FX0rbPJ yb9PoBDH41MQJ0br3WvtoufoPD1q2YM= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-443-y90K1yC_ODyAJ726flrH8Q-1; Tue, 08 Aug 2023 16:14:45 -0400 X-MC-Unique: y90K1yC_ODyAJ726flrH8Q-1 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2b9f0b7af1cso66560991fa.3 for ; Tue, 08 Aug 2023 13:14:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691525684; x=1692130484; 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=znyiJyK0+LqGR8XmS1U6TkGYktFtY45iVgfiwKJdAqk=; b=C5YKFzfXBK9/iWUiVMQ1R/YU5iXxP/JbWPGujfCnKx57ULsBBiPoBqyiJTL+YWo7Rw RV9IyTkUxH7aqzTTObmxHVwXxTYZkUGJQTCdo076t/OcJUcbhlki05gBpvalUyLbYE8L dUCirnIHlHEwnH+FCmEcibUdZ00/L9EvXNXwp6wsqECJI3sN6miOyiqlqs1drpgvhPc9 8V75OjgxBUy7EOaENevHD819PgBSZXQYe5jcz8C3fzRWCK6E/Uv0dY5wYDdBPzz42KZf rHF+rx+U0d2U8rmHyMvr10WzPb2K423BJHRIGCAmwo5RwEVzaBE/RsfitobO2Tsc36Hz +jog== X-Gm-Message-State: AOJu0YxIOP7zW0PK/xQo9D9aKZFxO5u+L+UJXUhE6J7zQT6KxU1z8wyw XL2hJfyQBJdMkqJ8Gp7j2671qydr/V3QydJb7uaJ6YIXmOzw+gNJNeR9u8Jt8xYqOQFDzdibsGz wci9F9YzsDgVyYilyiZWK/x/K2k97N7N2IA== X-Received: by 2002:a05:651c:1204:b0:2b9:43a7:376e with SMTP id i4-20020a05651c120400b002b943a7376emr390563lja.29.1691525684247; Tue, 08 Aug 2023 13:14:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGx/6Cj/XN+wcuGNCqVQy+WlxUR7VhTbJoE8HMRTAaD2x4bqz2nOYsU6X39/dPphiLGPL8/P/yFuiePiy4URwk= X-Received: by 2002:a05:651c:1204:b0:2b9:43a7:376e with SMTP id i4-20020a05651c120400b002b943a7376emr390555lja.29.1691525683916; Tue, 08 Aug 2023 13:14:43 -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: Jonathan Wakely Date: Tue, 8 Aug 2023 21:14:32 +0100 Message-ID: Subject: Re: [PATCH v2 3/3] libstdc++: Optimize is_fundamental performance by __is_arithmetic built-in To: Ken Matsui Cc: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= , Ken Matsui , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000084cc0a06026f035a" X-Spam-Status: No, score=-12.1 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_H4,RCVD_IN_MSPIKE_WL,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: --00000000000084cc0a06026f035a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 18 Jul 2023 at 07:28, Ken Matsui via Libstdc++ < libstdc++@gcc.gnu.org> 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 (because it doesn't have to conform to the full requirements of std::disjunction). A compiler built-in for __or_ / __disjunction might perform better. But eventually 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. > > 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-disjun= ction.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<_T= p> > > >::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_arithmetic > > > > > built-in trait. > > > > > (is_fundamental): Likewise. Optimize the original > implementation. > > > > > > > > > > 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 much > better that std::is_arithmetic. But __or_ could still avoid instantiation > of is_null_pointer. > > > > > > > Let me take a benchmark for this later. > > --00000000000084cc0a06026f035a--