From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by sourceware.org (Postfix) with ESMTPS id BAE4F3858CDA for ; Fri, 24 Mar 2023 11:03:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BAE4F3858CDA 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-qt1-f175.google.com with SMTP id r5so1093957qtp.4 for ; Fri, 24 Mar 2023 04:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1679655801; 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=9OfNnbosNO/Ext1xk2CzPt9vPRG+6OHzuZ0JeQMExSw=; b=b7IFwSfkp/GTSUwCyOJIvHidIxFzBMWrfKFnP0kA7gIbDJy72LIRXSrfff0sCt9wvZ buwEJWTlOv/EgXijClEMCgjpUTX9sQ6uQ7KZdJhsAZMr+dujVkMsSoOcnjLaYWlHrhCC BawPg/37aBBQnAjtrpl+gVILURv3tD6FWPOK0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679655801; 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=9OfNnbosNO/Ext1xk2CzPt9vPRG+6OHzuZ0JeQMExSw=; b=mf5MMtrr9n8lxO6GUCXJ9zHxWY1upe6h7LUCL8QnBuwBZ1nAJh2CJMgenC5N8c1FYp SDT9Lh20cErN0vaJp7NpE/Pe7XgT4BYALvs+s0NyOXqkqEEoGEyB39pSMBxyU84Q0PrB g5qz3glhIJsTKF2NvOUwYJxujQFzqRVb6f20YPDLT+lGPsgkyIAzEbEhgl/8MgSUFpbR mFwyNjpjnb35zp3pUSv11ol8ool3SKo3PKYJx7EYmpHyq9/6mRuLaUzxJTM2yswpA6sQ pnUtc+vc+bKQl5Q7Ynm4WIjM34/+HcutxygEctYwsfPgsydkBbUILd68ZmaCuQld6+oZ X2Jg== X-Gm-Message-State: AO0yUKXuLz3SYAuLr2Gejsth7eGhHlBj95t5hu7/S3b/cWKw25dyoaDL W6NBFudp+CUDH2X1ZYHbDtTB2dNkxLG5XRnNxJ4mIirlVo5Ul/n/Fsg= X-Google-Smtp-Source: AKy350ZHxtOzYM2SpZtyPHg/ZOVqCEMvcq3QfZCv9TlCk/xk/jczvmvhMsOhUGl14jn9kTcxdVlmNv0BohcG3Gsh+Dc= X-Received: by 2002:a67:c319:0:b0:425:de7e:3dce with SMTP id r25-20020a67c319000000b00425de7e3dcemr1117796vsj.6.1679654498333; Fri, 24 Mar 2023 03:41:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ken Matsui Date: Fri, 24 Mar 2023 03:41:27 -0700 Message-ID: Subject: Re: [GSoC] Question about Relatively Simple Library Traits To: Jonathan Wakely Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: On Fri, Mar 24, 2023 at 3:06=E2=80=AFAM Jonathan Wakely wrote: > > On Fri, 24 Mar 2023 at 09:58, Jonathan Wakely wro= te: > > > > On Fri, 24 Mar 2023 at 07:10, Ken Matsui via Gcc wrot= e: > > > > > > Hi, > > > > > > I am working on the GSoC project, "C++: Implement compiler built-in > > > traits for the standard library traits". I found the following librar= y > > > traits that I am not sure if implementing built-in traits brings > > > reasonable speed up. > > > > > > * std::is_fundamental > > > * std::is_arithmetic > > > * std::is_scalar > > > * std::is_object > > > * std::is_compound > > > * std::is_scoped_enum > > > > > > For example, std::is_object has no template specializations, but its > > > inheriting class looks complicated. > > > > > > __not_<__or_, is_reference<_Tp>, is_void<_Tp>>>::typ= e > > > > > > If we define the built-in trait for this trait, we have: (as > > > equivalence of the above code) > > > > > > __bool_constant<__is_object(_Tp)> > > > > > > And __is_object built-in trait should be like: > > > > > > !(type1 =3D=3D FUNCTION_TYPE || type1 =3D=3D ...) > > > > > > In this case, could someone tell me which one would be faster? Or, is > > > there no other way to know which but to benchmark? > > > > You should benchmark it anyway, I was always expecting that to be a > > part of this GSoC project :-) > > > > But is_object is NOT a "relatively simple" trait. What you show above > > is very complex. One of the more complex traits we have. Partial > > specializations are quite fast to match (in general) so eliminating > > partial speclializations (e.g. like we have for is_const) should not > > be the goal. > > > > For is_object we instantiate: > > > > is_function > > is_const > > is_reference > > is_void > > __bool_constant > > __or_ > > __not_ > > __bool_constant > > > > This is a ton of work! Instantiating class templates is the slowest > > part of trait evaluation, not matching partial specializations. > > And then if the same program also instantiates is_object (without > the const), then currently we instantiate: > > is_function > is_const > is_reference > is_void > __bool_constant > __or_ > __not_ > __bool_constant > > The first four instantiations are not shared with is_object int>, so we have to instantiate them anew. The last four are common > with is_object so don't need to be instantiated again, the > compiler will have cached those instantiations. > But if the same program also uses is_object then we have another > four new instantiations to generate. And another four for > is_object. And another four for is_object etc. > etc. > > With a built-in they will all use __bool_constant and nothing > else (apart from the top-level is_object specialization itself, > which is unavoidable* since that's the trait actually being > evaluated). > > * In fact, it's not really unavoidable, MSVC avoids it entirely. Their > compiler pattern matches the standard traits and never even > instantiates them, so every use of is_object::value gets expanded > directly to __is_object(T) without instantiating anything. We don't do > that, and if we just replace turn 8 or 9 class template instantiations > into 1 then we'll be doing great. Thank you so much for your detailed explanation! I totally did not understand well what class templates were doing! (And yes, I need to prepare my environment to take benchmarks...) So, do we expect to have __is_object built-in trait? Since std::is_object is a combination of multiple traits, would doing the following be the best implementation over implementing __is_object(T)? (you told me that built-ins make the compiler slightly bigger and slower) __bool_constant This would instantiate only __bool_constant and __bool_constant, which can be mostly shared, and we can also avoid adding an additional built-in. Sincerely, Ken Matsui