From: Richard Biener <richard.guenther@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Dongsheng Song <dongsheng.song@gmail.com>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
Tom Stellard <tstellar@redhat.com>,
"llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org>,
"Mallappa, Premachandra" <Premachandra.Mallappa@amd.com>,
"x86-64-abi@googlegroups.com" <x86-64-abi@googlegroups.com>
Subject: Re: New x86-64 micro-architecture levels
Date: Wed, 22 Jul 2020 15:50:14 +0200 [thread overview]
Message-ID: <CAFiYyc1guvEQf1bAt9bRj585tovfW=XV15bzwnQPVfervyu1gQ@mail.gmail.com> (raw)
In-Reply-To: <87365jkg6t.fsf@oldenburg2.str.redhat.com>
On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Richard Biener:
>
> > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
> >>
> >> * Dongsheng Song:
> >>
> >> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> >> > recommend using isa tags by year (e.g. x64_2010, x64_2014) like the
> >> > python's platform tags (e.g. manylinux2010, manylinux2014).
> >>
> >> I started out with a year number, but that was before the was Level A.
> >> Too many new CPUs only fall under level A unfortunately because they do
> >> not even have AVX. This even applies to some new server CPU designs
> >> released this year.
> >>
> >> I'm concerned that putting a year into the level name suggests that
> >> everything main-stream released after that year supports that level, and
> >> that's not true. I think for manylinux, it's different, and it actually
> >> works out there. No one is building a new GNU/Linux distribution that
> >> is based on glibc 2.12 today, for example. But not so much for x86
> >> CPUs.
> >>
> >> If you think my worry is unfounded, then a year-based approach sounds
> >> compelling.
> >
> > I think the main question is whether those levels are supposed to be
> > an implementation detail hidden from most software developer or
> > if people are expected to make concious decisions between
> > -march=x86-100 and -march=x86-101. Implementation detail
> > for system integrators, that is.
>
> Anyone who wants to optimize their software something that's more
> current than what was available in 2003 has to think about this in some
> form.
>
> With these levels, I hope to provide a pre-packaged set of choices, with
> a consistent user interface, in the sense that -march= options and file
> system locations match. Programmers will definitely encounter these
> strings, and they need to know what they mean for their users. We need
> to provide them with the required information so that they can make
> decisions based on their knowledge of their user base. But the ultimate
> decision really has to be a programmer choice.
>
> I'm not sure if GCC documentation or glibc documentation would be the
> right place for this. An online resource that can be linked to directly
> seems more appropriate.
>
> Apart from that, there is the more limited audience of general purpose
> distribution builders. I expect they will pick one of these levels to
> build all the distribution binaries, unless they want to be stuck in
> 2003. But as long they do not choose the highest level defined,
> programmers might still want to provide optimized library builds for
> run-time selection, and then they need the same guidance as before.
>
> > If it's not merely an implementation detail then names without
> > any chance of providing false hints (x86-2014 - oh, it will
> > run fine on the CPU I bought in 2015; or, x86-avx2 - ah, of
> > course I want avx2) is better. But this also means this feature
> > should come with extensive documentation on how it is
> > supposed to be used. For example we might suggest ISVs
> > provide binaries for all architecture levels or use IFUNCs
> > or other runtime CPU selection capabilities.
>
> I think we should document the mechanism as best as we can, and provide
> intended use cases. We shouldn't go as far as to tell programmers what
> library versions they must build, except that they should always include
> a fallback version if no optimized library can be selected.
>
> Describing the interactions with IFUNCs also makes sense.
>
> But I think we should not go overboard with this. Historically, we've
> done not such a great job with documenting toolchain features, I know,
> and we should do better now. I will try to write something helpful, but
> it should still match the relative importance of this feature.
>
> > It's also required to provide a (extensive?) list of SKUs that fall
> > into the respective categories (probably up to CPU vendors to amend
> > those).
>
> I'm afraid, but SKUs are not very useful in this context.
> Virtualization can disable features (e.g., some cloud providers
> advertise they use certain SKUs, but some features are not available to
> guests), and firmware updates have done so as well. I think the only
> way is to document our selection criteria, and encourage CPU vendors to
> enhance their SKU browsers so that you can search by the (lack of)
> support for certain CPU features.
>
> The selection criteria I suggested should not be affected by firmware
> and microcode updates at least (I took that into consideration), but
> it's just not possible to achieve virtualization and kernel version
> independence, given that some features based on which we want to make
> library selections demand kernel and hypervisor support.
>
> > Since this is a feature crossing multiple projects - at least
> > glibc and GCC - sharing the source of said documentation
> > would be important.
>
> Technically, the GCC web site would work for me. It's not a wiki. It's
> not CVS. We can update it outside of release cycle. We are not forced
> to use the GFDL with Invariant Sections. It doesn't end up in our
> product documentation, where it would be confusing if it discusses
> unsupported CPUs.
>
> Everything that can be installed locally becomes outdated and
> problematic. The psABI supplement is a PDF document, so we can't easily
> link to the appropriate section. The specification found there would
> also not be targeted at programmers, but rather at compiler and dynamic
> linker writers.
>
> Did you have something else in mind?
Not really - the whole stuff just adds to the ways ISV could optimize
their binaries all of which are not very well documented in a place
that discusses such optimization ...
But yeah, extensively documenting all the ways and reasons
to optimize binaries is certainly out-of-scope for the task of
adding just one other way.
So a website works for me. Having a source representation
of said website that is easy to embed into a whitepaper or
even GCCs texi documentation for example would of course
be nice.
Richard.
> > So for the bike-shedding I indeed think x86-10{0,1,2,3}
> > or x86-{A,B,C,..}, eventually duplicating as x86_64- as
> > suggested by Jan is better than x86-2014 or x86-avx2.
>
> I'll comment separately on the prefix matter.
>
> Thanks,
> Florian
>
next prev parent reply other threads:[~2020-07-22 13:50 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 17:30 Florian Weimer
2020-07-10 19:14 ` Joseph Myers
2020-07-13 7:55 ` Florian Weimer
2020-07-10 21:42 ` H.J. Lu
2020-07-13 6:23 ` Richard Biener
2020-07-13 7:40 ` Florian Weimer
2020-07-13 7:47 ` Jan Beulich
2020-07-13 13:31 ` H.J. Lu
2020-07-13 13:53 ` Jakub Jelinek
2020-07-13 8:57 ` Richard Biener
2020-07-13 6:49 ` Florian Weimer
2020-07-13 13:30 ` H.J. Lu
2020-07-11 7:40 ` Allan Sandfeld Jensen
2020-07-13 6:58 ` Florian Weimer
2020-07-15 14:38 ` Mark Wielaard
2020-07-15 14:45 ` H.J. Lu
2020-07-15 14:56 ` Florian Weimer
2020-07-21 16:05 ` Mallappa, Premachandra
2020-07-21 18:04 ` Florian Weimer
2020-07-22 1:31 ` Dongsheng Song
2020-07-22 8:44 ` Florian Weimer
2020-07-22 9:26 ` Richard Biener
2020-07-22 10:16 ` Florian Weimer
2020-07-22 13:50 ` Richard Biener [this message]
2020-07-22 14:21 ` H.J. Lu
2020-07-31 13:06 ` Carlos O'Donell
2020-07-22 7:48 ` Jan Beulich
2020-07-22 10:34 ` Florian Weimer
2020-07-22 11:41 ` Jan Beulich
2020-07-31 13:20 ` Carlos O'Donell
2020-07-22 16:45 ` Mallappa, Premachandra
2020-07-23 12:44 ` Michael Matz
2020-07-23 13:21 ` H.J. Lu
2020-07-28 15:54 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFiYyc1guvEQf1bAt9bRj585tovfW=XV15bzwnQPVfervyu1gQ@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=Premachandra.Mallappa@amd.com \
--cc=dongsheng.song@gmail.com \
--cc=fweimer@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=llvm-dev@lists.llvm.org \
--cc=tstellar@redhat.com \
--cc=x86-64-abi@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).