llvm dev - Jul 2020 - New x86-64 micro-architecture levels

* Richard Biener:
> On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc at
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?
> 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

On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer <fweimer at redhat.com>
wrote:
>
> * Richard Biener:
>
> > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc at
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
>

On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha
<libc-alpha at sourceware.org> wrote:
>
> On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer <fweimer at
redhat.com> wrote:
> >
> > * Richard Biener:
> >
> > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc
at 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.
We made up -march=x86-64.   We can extend pseudo x86-64
with more variants.


-- 
H.J.