This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc


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.
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]