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.133.124]) by sourceware.org (Postfix) with ESMTP id 498903857421 for ; Fri, 16 Jul 2021 15:31:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 498903857421 Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-250-pB7Y81pRNfCI4pDOY4fkJA-1; Fri, 16 Jul 2021 11:31:12 -0400 X-MC-Unique: pB7Y81pRNfCI4pDOY4fkJA-1 Received: by mail-pg1-f200.google.com with SMTP id 29-20020a63105d0000b029022c245c3492so7208825pgq.17 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=JCTHKvoFM/+I929ZQQigCdMV7z12sWz2HN/67iDk5jETb/eS22OYyZ3M20kUYaNS2J AteR9fHlb+ifXfb+TYG86PS/c5WskLjYhttvJnCcBJor1mwZlpj/lnUuOXT4tKtJX3v8 RgWxHrwRudiMboXLCpCcQEumx3KWAyM4IT+9RpufmkFBU5o+Q9uPd1OYxd0sQA06OHad B3STxshw6yUEfFlYPu/xZ9wLbEf5FweJjmquIWcVrjhKGG1IhKypcfUl/LBdV7N29I52 +/QD7d5Fomcx4ar7eS+ae4JU2yh5THBZ1aU1HWOFFz2HfkmTHT/SxHkveS8fF8nr3Ccr HulQ== X-Gm-Message-State: AOAM533aQirYrTrqaitAr60jYaBf3gL+7o8Fr7uNvq6KomXKdiVdxF5q lo+SIRNAqsYs36rYSxNExxF18tRVQ+vLottrBDkmTjyTgzf5VHK5K5qfjv+s9r0AqisgFwfi6Ad nTRWXdb9fbrDflH2CkgqmEIbJBoa1223yoomQ X-Received: by 2002:a17:902:a513:b029:11a:9be6:f1b9 with SMTP id s19-20020a170902a513b029011a9be6f1b9mr8180511plq.55.1626449471206; 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.7 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=unavailable 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha 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 >