This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, "Zamyatin, Igor" <igor dot zamyatin at intel dot com>, Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, "Melik-Adamyan, Areg" <areg dot melik-adamyan at intel dot com>, "jakub at redhat dot com" <jakub at redhat dot com>
- Date: Fri, 12 Sep 2014 18:47:27 -0400
- Subject: Re: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3t=ppndDUBzHzSus7xyuF5hTaLFZ5b273jD39NtddSvsw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409101549490 dot 12853 at digraph dot polyomino dot org dot uk> <5411F8D3 dot 7050001 at redhat dot com> <0EFAB2BDD0F67E4FB6CCC8B9F87D756969B4D6D8 at IRSMSX101 dot ger dot corp dot intel dot com> <Pine dot LNX dot 4 dot 64 dot 1409112047460 dot 5583 at digraph dot polyomino dot org dot uk> <CAMe9rOqXPoORKoqWXYCSBbpuketbQf-enBk60xPq5O_yOo+i5A at mail dot gmail dot com> <541239E7 dot 8070806 at redhat dot com> <CAMe9rOpbWjvOZpJzypn8FA3USu4XyTY=MTvOn+0eQt5fb0Fq_Q at mail dot gmail dot com> <54130CC8 dot 7060106 at redhat dot com> <1410537638 dot 4967 dot 103 dot camel at triegel dot csb> <54132F6E dot 9010208 at redhat dot com> <1410561528 dot 4967 dot 121 dot camel at triegel dot csb>
On 09/12/2014 06:38 PM, Torvald Riegel wrote:
>> That is correct. However it also requires a much much much more complicated
>> API design because it has to map optimally to an arbitrarily different
>> future hardware design that we don't know of yet. We might extrapolate
>> that AVX-512 -> 1024 -> 2048 -> 4096 etc, and design in that direction
>> for all machines. Not to mention unified error reporting. It's a harder
>> problem that exposing, for now, the vendor APIs as a starting point,
>> as a place where the community can learn about the issues behind these
>> APIs and design something new.
>
> The language-level interfaces I was speaking about (they're not exactly
> APIs) are different. They have to expose some of the complexity you
> mention (see the Cilk+ elemental functions), but hide a lot in the
> compiler. Standards-wise, the current direction does not seem to go
> towards trying to have portable APIs for vector instructions, but rather
> let programmers specify that SIMD parallelism is allowed and then give a
> few hints about how a programmer-supplied function might be used (e.g.,
> that one argument is always linear, etc.). That's why I said that we'd
> have complexity in the ABIs (and in the compiler), but are not exposing
> a lot of that to programmers via APIs.
That makes a certain amount of sense, but with the Intel functions
documented the developers expect to be able to write bespoke loops
and call those functions.
Perhaps for the generic implementation we may chose not to expose
that to programmers.
c.