From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id E70EA39A7434 for ; Fri, 16 Jul 2021 13:27:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E70EA39A7434 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D9CAD6E; Fri, 16 Jul 2021 06:27:28 -0700 (PDT) Received: from [10.57.6.202] (unknown [10.57.6.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4D5863F774; Fri, 16 Jul 2021 06:27:27 -0700 (PDT) Subject: Re: [PATCH] c++: implement C++17 hardware interference size To: Jonathan Wakely , Noah Goldstein Cc: "Richard Earnshaw (lists)" , libstdc++ , gcc-patches List , GNU C Library References: <20210716023656.670004-1-jason@redhat.com> From: Richard Earnshaw Message-ID: <75a6763b-4547-959c-cc3a-0474dba7b020@foss.arm.com> Date: Fri, 16 Jul 2021 14:27:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1164.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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 13:27:30 -0000 On 16/07/2021 12:17, Jonathan Wakely via Gcc-patches wrote: > On Fri, 16 Jul 2021 at 03:51, 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-32-architectures-optimization-manual.pdf#page=60 > > Which is a good example of why these "constants" should never have > been standardized in the first place. Sigh. > +1 for that. I'll have a chat with our architecture guys, but I've no idea if they'll commit to any (useful) values for either constant. R.