From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 8320B3858024 for ; Fri, 26 Mar 2021 12:12:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8320B3858024 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (port=49747 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lPlK7-0002Im-Tm; Fri, 26 Mar 2021 12:12:19 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1lPlK7-0008A8-Q0; Fri, 26 Mar 2021 13:12:19 +0100 From: Florian Weimer To: Andy Lutomirski Cc: "H. J. Lu" , X86 ML , LKML , "Bae\, Chang Seok" , "Carlos O'Donell" , Rich Felker , Subject: Re: Why does glibc use AVX-512? References: Date: Fri, 26 Mar 2021 13:12:19 +0100 In-Reply-To: (Andy Lutomirski via Libc-alpha's message of "Thu, 25 Mar 2021 21:38:24 -0700") Message-ID: <87a6qqi064.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 26 Mar 2021 12:12:40 -0000 * Andy Lutomirski-alpha: > glibc appears to use AVX512F for memcpy by default. (Unless > Prefer_ERMS is default-on, but I genuinely can't tell if this is the > case. I did some searching.) The commit adding it refers to a 2016 > email saying that it's 30% on KNL. As far as I know, glibc only does that on KNL, and there it is actually beneficial. The relevant code is: /* Since AVX512ER is unique to Xeon Phi, set Prefer_No_VZEROUPPER if AVX512ER is available. Don't use AVX512 to avoid lower CPU frequency if AVX512ER isn't available. */ if (CPU_FEATURES_CPU_P (cpu_features, AVX512ER)) cpu_features->preferred[index_arch_Prefer_No_VZEROUPPER] |= bit_arch_Prefer_No_VZEROUPPER; else cpu_features->preferred[index_arch_Prefer_No_AVX512] |= bit_arch_Prefer_No_AVX512; So it's not just about Prefer_ERMS. > I think we should seriously consider solutions in which, for new > tasks, XCR0 has new giant features (e.g. AMX) and possibly even I think the AMX programming model will be different, yes. > AVX-512 cleared, and programs need to explicitly request enablement. > This would allow programs to opt into not saving/restoring across > signals or to save/restore in buffers supplied when the feature is > enabled. Isn't XSAVEOPT already able to handle that? In glibc, we use XSAVE/XSAVEC for the dynamic loader trampoline, so it should not needlessly enable AVX-512 state today, while still enabling AVX-512 calling conventions transparently. There is a discussion about using the higher (AVX-512-only) %ymm registers, to avoid the %xmm transition penalty without the need for VZEROUPPER. (VZEROUPPER is incompatible with RTM from a performance point of view.) That would perhaps negatively impact XSAVEOPT. Assuming you can make XSAVEOPT work for you on the kernel side, my instincts tell me that we should have markup for RTM, not for AVX-512. This way, we could avoid use of the AVX-512 registers and keep using VZEROUPPER, without run-time transaction checks, and deal with other idiosyncrasies needed for transaction support that users might encounter once this feature sees more use. But the VZEROUPPER vs RTM issues is currently stuck in some internal process issue on my end (or two, come to think of it), which I hope to untangle next month.