From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 531F93858CDA for ; Fri, 24 Mar 2023 10:29:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 531F93858CDA 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-lj1-x22c.google.com with SMTP id q14so1184604ljm.11 for ; Fri, 24 Mar 2023 03:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679653782; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZURXccyXvTfCWalY1lWpsgCBR/jFZa0zFIaiQS96FSg=; b=bpm54Ngfirf4+tFCRSr3MAaGMtRDQwlvxfRBNpXa61dIpg2ACkJbU+7UZYwdB++C2j MpOL852hnc8/GcMyau0F0jd8h10ReaA3ZlKs2UMr5Jkdzxnry4j8+I5SnrcNuVEIgEfQ c/HYTxLOWiqhA3aK8XIXQQYGq2gdaxpZPIUb28FKvDa+nGxS6MUxSEMJTPMC40bmZJPG cfYA2QICmVHUeX+0x5e3mwmxtQd+yRfQ2lRzDeFqn45lfAqFKWMUY3N+Z/nGy7QeQbhM b6FyRzXMn3/xPUX8bR52P3ZawHza0+irV21swvCEYNDcr866/m7lR+Z6mZCjd5PWjpTu JbnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679653782; 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=ZURXccyXvTfCWalY1lWpsgCBR/jFZa0zFIaiQS96FSg=; b=0MrM7FNmJZHB49nlZeHej3aWcFne678QrN6pYJ/rhuG9JqWImG4umH7XjmPVsGfbXT XAi+9gTs3MCtsNqd0RknYgg6r5ovzdSX1NzH3rSVbJy71UZAXu5+ucW8x9tnrZok331/ pY/oVbhgjOtWi1snpDhy9AXhoLlH+w6q80relrONmhLRAAnNo31mNZvSV8Zz/Z/9U3Aa d9yOMX+i3WgQDVjDl/jCbLXiID13AajKRYPxvHK6k1memiFsLCwY16TOvhMN/0I8zi+f UxggphY0BSJWtqcRCRGBHUOZr4o1C1jK0LrNRMjZU/caatTDHum7fk4hYZjff/L6PeZO 67dw== X-Gm-Message-State: AAQBX9feo3G+UUY+obhFUKtxYLMMFflEfPZCvrN2dLH1V6PWGACbixSN XruWkYY5RnYGbpxR6fo4QmeUwqrIjHP50UMxcKUxJH3Sa7E= X-Google-Smtp-Source: AKy350aK3p5TbHVAXmIPxGrnnT8HP0/73OGP5jdxm3/Unf49Zv04fYHBBmcBFg0l9xuY9m5ezjToSlAh2Ei9Ls4ZXzU= X-Received: by 2002:a17:907:7614:b0:930:a3ee:f22e with SMTP id jx20-20020a170907761400b00930a3eef22emr1054243ejc.13.1679652340057; Fri, 24 Mar 2023 03:05:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 24 Mar 2023 10:05:29 +0000 Message-ID: Subject: Re: [GSoC] Question about Relatively Simple Library Traits To: Ken Matsui Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Fri, 24 Mar 2023 at 09:58, Jonathan Wakely wrote: > > On Fri, 24 Mar 2023 at 07:10, Ken Matsui via Gcc wrote: > > > > Hi, > > > > I am working on the GSoC project, "C++: Implement compiler built-in > > traits for the standard library traits". I found the following library > > 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>>>::type > > > > 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 == FUNCTION_TYPE || type1 == ...) > > > > 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, 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.