From: Segher Boessenkool <segher@kernel.crashing.org>
To: Rich Felker <dalias@libc.org>
Cc: libc-alpha@sourceware.org, eery@paperfox.es,
"Daniel Kolesa" <daniel@octaforge.org>,
musl@lists.openwall.com,
"Will Springer" <skirmisher@protonmail.com>,
"Palmer Dabbelt via binutils" <binutils@sourceware.org>,
"via libc-dev" <libc-dev@lists.llvm.org>,
"Michal Suchánek" <msuchanek@suse.de>,
linuxppc-dev@lists.ozlabs.org,
"Joseph Myers" <joseph@codesourcery.com>
Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
Date: Fri, 5 Jun 2020 18:45:23 -0500 [thread overview]
Message-ID: <20200605234523.GU31009@gate.crashing.org> (raw)
In-Reply-To: <20200605175045.GW1079@brightrain.aerifal.cx>
Hi!
On Fri, Jun 05, 2020 at 01:50:46PM -0400, Rich Felker wrote:
> On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote:
> > > I'm also not really all that convinced that vectors make a huge difference in non-specialized code (autovectorization still has a way to go)
> >
> > They do make a huge difference, depending on the application of course.
> > But VSX is not just vectors even: it also gives you twice as many
> > floating point scalars (64 now), and in newer versions of the ISA it can
> > be beneficially used for integer scalars even.
>
> Vectorization is useful for a lot of things, and I'm sure there are
> specialized workloads that benefit from 64 scalars, but I've never
> encountered a place where having more than 16 registers made a
> practical difference.
20 years ago 32 FP registers was already often a limitation, making FFT
and similar kernels almost twice slower than they could otherwise be.
Things are only *worse* with short vectors, not better. In general with
floating point data you need more registers (because you have more state
to look at concurrently) than with integer data.
*Of course* having 64 floating point registers does not matter if your
whole program only ever uses three floating point values, total, let
alone concurrently.
> The fact that there are specialized areas where this stuff matters
> does not imply there aren't huge domains where it's completely
> irrelevant.
There are very few domains where ISA 2.07 does not have significant
advantages over ISA 2.01. That is Power8 vs. Power4.
> > No, that is exactly the point of requiring ISA 2.07. Anything can use
> > ISA 2.07 (incl. VSX) without checking first, and without having a
> > fallback to some other implementation. Going from ISA 2.01 to 2.07 is
> > more than a decade of improvements, it is not trivial at all.
>
> This only affects code that's non-portable and PPC-specific, which a
No, it does not. It is not only about vector registers, either.
> I think a lot of the unnecessary fighting on this topic is arising
> from differences of opinion over what an ABI entails. I would call
> what you're talking about a "platform" and more of a platform-specific
> *API* than an ABI -- it's about guarantees of interfaces available to
> the programmer, not implementation details of linkage.
No, this is very much about the ABI. The B stands for Binary. Which
is what this is about.
Segher
next prev parent reply other threads:[~2020-06-05 23:47 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 19:03 ppc64le and 32-bit LE userland compatibility Will Springer
2020-05-29 19:24 ` [musl] " Rich Felker
2020-05-30 22:56 ` Will Springer
2020-06-09 10:29 ` Will Springer
2020-06-09 16:06 ` Rich Felker
2020-05-30 15:37 ` Christophe Leroy
2020-05-30 22:17 ` Will Springer
2020-06-05 23:54 ` Will Springer
2020-06-12 5:13 ` Christophe Leroy
2020-05-30 19:22 ` Segher Boessenkool
2020-05-31 0:57 ` Will Springer
2020-05-31 20:42 ` Segher Boessenkool
2020-05-31 22:29 ` [musl] " Daniel Kolesa
2020-06-02 1:36 ` Segher Boessenkool
2020-06-01 21:28 ` Joseph Myers
2020-06-01 21:36 ` [musl] " Rich Felker
2020-06-01 23:26 ` Daniel Kolesa
2020-06-01 23:45 ` Joseph Myers
2020-06-01 23:55 ` Joseph Myers
2020-06-02 0:13 ` Daniel Kolesa
2020-06-02 0:11 ` Daniel Kolesa
2020-06-02 13:40 ` Joseph Myers
2020-06-02 14:23 ` Michal Suchánek
2020-06-02 15:13 ` Daniel Kolesa
2020-06-02 15:27 ` Michal Suchánek
2020-06-02 15:40 ` Daniel Kolesa
2020-06-02 15:56 ` Michal Suchánek
2020-06-04 17:20 ` Segher Boessenkool
2020-06-04 17:12 ` Segher Boessenkool
2020-06-04 17:18 ` [musl] " Rich Felker
2020-06-04 17:33 ` Segher Boessenkool
2020-06-04 17:46 ` Rich Felker
2020-06-04 19:00 ` David Edelsohn
2020-06-04 19:37 ` Rich Felker
2020-06-04 20:39 ` Daniel Kolesa
2020-06-04 21:10 ` Segher Boessenkool
2020-06-04 21:43 ` Daniel Kolesa
2020-06-04 22:08 ` Joseph Myers
2020-06-04 22:26 ` Daniel Kolesa
2020-06-05 0:02 ` Segher Boessenkool
2020-06-04 23:42 ` Segher Boessenkool
2020-06-04 23:35 ` Segher Boessenkool
2020-06-05 2:18 ` Daniel Kolesa
2020-06-05 17:27 ` Segher Boessenkool
2020-06-05 17:50 ` Rich Felker
2020-06-05 23:45 ` Segher Boessenkool [this message]
2020-06-05 21:59 ` Daniel Kolesa
2020-06-06 0:12 ` Segher Boessenkool
2020-06-06 2:13 ` Daniel Kolesa
2020-06-04 21:55 ` Phil Blundell
2020-06-04 22:06 ` Daniel Kolesa
2020-06-04 23:06 ` Segher Boessenkool
2020-06-04 23:43 ` Phil Blundell
2020-06-02 14:52 ` Daniel Kolesa
2020-06-02 2:12 ` Segher Boessenkool
2020-06-02 2:17 ` Daniel Kolesa
2020-06-02 13:50 ` Joseph Myers
2020-06-02 17:47 ` Segher Boessenkool
2020-06-02 1:58 ` Segher Boessenkool
2020-06-02 2:09 ` [musl] " Jeffrey Walton
2020-06-02 2:12 ` Daniel Kolesa
2020-06-02 2:36 ` Segher Boessenkool
2020-06-02 2:55 ` Daniel Kolesa
2020-06-02 1:42 ` Segher Boessenkool
2020-06-02 2:03 ` Daniel Kolesa
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=20200605234523.GU31009@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=binutils@sourceware.org \
--cc=dalias@libc.org \
--cc=daniel@octaforge.org \
--cc=eery@paperfox.es \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-dev@lists.llvm.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=msuchanek@suse.de \
--cc=musl@lists.openwall.com \
--cc=skirmisher@protonmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.