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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 429D03857830 for ; Fri, 16 Jul 2021 15:31:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 429D03857830 Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-401-b8eDKLl7M4avCrmH7SVxYg-1; Fri, 16 Jul 2021 11:31:12 -0400 X-MC-Unique: b8eDKLl7M4avCrmH7SVxYg-1 Received: by mail-pl1-f199.google.com with SMTP id m7-20020a170902db07b029012b543156e7so1414271plx.22 for ; Fri, 16 Jul 2021 08:31:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SjYe+CJXfAj97vP96gPGNP2JUrC0x0VQZoSaQ01zqq8=; b=AUhxUdG1/tUBjsLY/HLQv0thoeF7/3sJal/egQ+aDa98Yu+e+RQ78lw/9ltQNyncBb ywhmmwGjmZu9KSAlUzotMfPyzfIDlbRbXrXqrYmwrvEkR9Q2umCi7rNV+bpSAvTmwOQB +upeoHKxY3bZKiu/34suvpKm11wrYeE/rNnvY1kJGN2sdPDFun5CgN1jT4OmoFGl6omQ GVIrvb8OzmkgwG6uG13Yhx1Vj2h+37KwyINb0+vB8ASUWjdA98bPZp25g3o70E92STmY NjFJu+27lowrmI9ntzWxUbVmnzvJ93UX5uexCPMvnX21a+5XlG/k3kJ1xPVhwYedw9bY szuQ== X-Gm-Message-State: AOAM530Fz/hH2fqTr+bSoR79TQGtaTCX4QjDk62nQvr69HVMNaKowzpS AyMWep1GXG7gBytn/l4ZynvF9UTxpayygBS1OT/FsgCd2sKcdAMXDRmOIwSyyRbaQl6O+eNNYWZ D/2qMBkJoP+ogF5cwyCRf1u1cEy3ZQ5t9Vg== X-Received: by 2002:a17:902:a513:b029:11a:9be6:f1b9 with SMTP id s19-20020a170902a513b029011a9be6f1b9mr8180512plq.55.1626449471207; Fri, 16 Jul 2021 08:31:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyAWHKFhTVPaAaMpF9Ojqz09DcjzSc8IpAOVonO4eTse3HmCnD8qSEfD6Y4oPip8P1xTp59+LE6XC4Uqb7zYTI= X-Received: by 2002:a17:902:a513:b029:11a:9be6:f1b9 with SMTP id s19-20020a170902a513b029011a9be6f1b9mr8180487plq.55.1626449470839; Fri, 16 Jul 2021 08:31:10 -0700 (PDT) MIME-Version: 1.0 References: <20210716023656.670004-1-jason@redhat.com> <2136759.qKCeTcHjAi@excalibur> In-Reply-To: <2136759.qKCeTcHjAi@excalibur> From: Jason Merrill Date: Fri, 16 Jul 2021 11:30:59 -0400 Message-ID: Subject: Re: [PATCH] c++: implement C++17 hardware interference size To: Matthias Kretz Cc: gcc-patches List , "Richard Earnshaw (lists)" , "libstdc++" , libc-alpha@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 15:31:18 -0000 On Fri, Jul 16, 2021, 11:12 AM Matthias Kretz wrote: > On Friday, 16 July 2021 04:41:17 CEST Jason Merrill via Gcc-patches wrote: > > > Currently the patch does not adjust the values based on -march, as in > JF's > > > proposal. I'll need more guidance from the ARM/AArch64 maintainers > about > > > how to go about that. --param l1-cache-line-size is set based on > -mtune, > > > but I don't think we want -mtune to change these ABI-affecting values. > > > Are > > > there -march values for which a smaller range than 64-256 makes sense? > > As a user who cares about ABI but also cares about maximizing performance > of > builds for a specific HPC setup I'd expect the hardware interference size > values to be allowed to break ABIs. The point of these values is to give > me > better performance portability (but not necessarily binary portability) > than > my usual "pick 64 as a good average". > > Wrt, -march / -mtune setting hardware interference size: IMO -mtune=X > should > be interpreted as "my binary is supposed to be optimized for X, I accept > inefficiencies on everything that's not X". > > On Friday, 16 July 2021 04:48:52 CEST Noah Goldstein wrote: > > On intel x86 systems with a private L2 cache the spatial prefetcher > > can cause destructive interference along 128 byte aligned boundaries. > > > https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-3 > > 2-architectures-optimization-manual.pdf#page=60 > > I don't understand how this feature would lead to false sharing. But maybe > I > misunderstand the spatial prefetcher. The first access to one of the two > cache > lines pairs would bring both cache lines to LLC (and possibly L2). If a > core > with a different L2 reads the other cache line the cache line would be > duplicated; if it writes to it, it would be exclusive to the other core's > L2. > The cache line pairs do not affect each other anymore. Maybe there's a > minor > inefficiency on initial transfer from memory, but isn't that all? > > That said. Intel documents the spatial prefetcher exclusively for Sandy > Bridge. So if you still believe 128 is necessary, set the destructive > hardware > interference size to 64 for all of x86 except -mtune=sandybridge. > Adjusting them based on tuning would certainly simplify a significant use case, perhaps the only reasonable use. Cases more concerned with ABI stability probably shouldn't use them at all. And that would mean not needing to worry about the impossible task of finding the right values for an entire architecture. I'm thinking about warning by default for any use of the variables without explicitly specifying their values on the command line. Users could disable the warning if they're happy using whatever the defaults happen to be. Jason >