[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKmLth==ZPv7ygLs0jFX7JRPVhVT82ZDoT4xcQRABEVTvQ@mail.gmail.com>
Date: Tue, 13 Apr 2021 15:51:50 -0400
From: Len Brown <lenb@...nel.org>
To: Willy Tarreau <w@....eu>
Cc: Andy Lutomirski <luto@...nel.org>,
Florian Weimer <fweimer@...hat.com>,
"Bae, Chang Seok" <chang.seok.bae@...el.com>,
Dave Hansen <dave.hansen@...el.com>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>, linux-abi@...r.kernel.org,
"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
Rich Felker <dalias@...c.org>, Kyle Huey <me@...ehuey.com>,
Keno Fischer <keno@...iacomputing.com>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
Thanks for sharing your perspective, Willy.
I agree that if your application is so sensitive that you need to hand-code
your own memcmp, then linking with (any) new version of (any) dynamic library
is a risk you must consider carefully.
AMX does the type of matrix multiplication that AI algorithms use.
In the unlikely event that you or one of the libraries you call are
doing the same,
then you will be very happy with AMX. Otherwise, you'll probably not use it.
I acknowledge the issue with the toolchain transparently using AVX-512
for copying data, and how that approach impacted systems with
a poor AVX-512 hardware implementation. FWIW. I'm not aware of any
plans to implicitly use AMX this way, and I'm not aware of any non-Xeon
AMX implementations in the near future.
cheers,
Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists