Re: [Aarch64] libmvec development status

Re: [Aarch64] libmvec development status

[Wilco Dijkstra]

Andrew Pinski wrote:

> The main justification is that Ashwin is working on the libmvec too.
> He has proposed the ABI:
> https://gcc.gnu.org/ml/gcc/2017-03/msg00077.html
>
> Basically I would like this collaboration upstream rather than in the
> private and not on the mailing list.  Also delaying upstreaming the
> base support means there will be two versions out there in the wild
> starting soon.  This is not a good thing.

Agreed, there is no point in having 2 ABIs for the same feature.

> I think he means core specific versions.  For an example it might make
> sense to have a different version that is specific to ThunderX2
> CN99xx.  There are some specific instructions sequences are faster to
> do on cn99xx compared to other cores.

My general feeling is that the scope for microarchitecture specific tuning is
very limited. Most of the gains are due to (a) having a vector math function in
the first place, and (b) good algorithm&polynomial. After that you're typically
limited by FMUL/FMA latency with little potential for improvement (eg. using 
FMA may be essential to achieve the ULP goal, and the polynomial might have
been designed for FMA, so changing it would increase the worst-case error,
potentially significantly so).

Wilco

Re: [Aarch64] libmvec development status

[Sekhar, Ashwin]

On Friday 17 March 2017 01:19 AM, Wilco Dijkstra wrote:
> Andrew Pinski wrote:
>
>> The main justification is that Ashwin is working on the libmvec too.
>> He has proposed the ABI:
>> https://gcc.gnu.org/ml/gcc/2017-03/msg00077.html
>>
>> Basically I would like this collaboration upstream rather than in the
>> private and not on the mailing list.  Also delaying upstreaming the
>> base support means there will be two versions out there in the wild
>> starting soon.  This is not a good thing.
>
> Agreed, there is no point in having 2 ABIs for the same feature.
Since ARM has already started working on libmvec, I believe the ABI 
would already be in place (atleast as a draft). Appreciate if ARM could 
share the same.
>
>> I think he means core specific versions.  For an example it might make
>> sense to have a different version that is specific to ThunderX2
>> CN99xx.  There are some specific instructions sequences are faster to
>> do on cn99xx compared to other cores.
>
> My general feeling is that the scope for microarchitecture specific tuning is
> very limited. Most of the gains are due to (a) having a vector math function in
> the first place, and (b) good algorithm&polynomial. After that you're typically
> limited by FMUL/FMA latency with little potential for improvement (eg. using
> FMA may be essential to achieve the ULP goal, and the polynomial might have
> been designed for FMA, so changing it would increase the worst-case error,
> potentially significantly so).
>
> Wilco
>

Ashwin

Re: [Aarch64] libmvec development status

[Andrew Pinski]

On Thu, Mar 16, 2017 at 6:02 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 16/03/17 06:29, Sekhar, Ashwin wrote:
>> Hi Glibc Team, Aarch64 Maintainers,
>>
>> Could you please let us know what is the status of libmvec development for Aarch64?
>>
>> Saw in this linaro talk (https://www.youtube.com/watch?v=QBOOrJnqo9A) that ARM is actively working on this. Would appreciate if you could throw some light on when we can expect this to be upstreamed.
>>
>
> gcc-7 (in stage 4) won't have the necessary support for aarch64
> libmvec so it's hard to justify the urgency, i.e. upstreaming
> most likely won't happen in this glibc release cycle.
> (some discussions can start earlier though.)

The main justification is that Ashwin is working on the libmvec too.
He has proposed the ABI:
https://gcc.gnu.org/ml/gcc/2017-03/msg00077.html

Basically I would like this collaboration upstream rather than in the
private and not on the mailing list.  Also delaying upstreaming the
base support means there will be two versions out there in the wild
starting soon.  This is not a good thing.

>
>> Also, would appreciate if you could upstream a base code for aarch64 libmvec (need not contain any API implementations) so that it would enable others to work on target specific implementations. Would like to know your comments on the feasibility of this request.
>>
>
> i'm not sure what target specific implementation means in this
> context: i expected at most two sets of math functions for the
> two aarch64 simd variants (advsimd and sve).

I think he means core specific versions.  For an example it might make
sense to have a different version that is specific to ThunderX2
CN99xx.  There are some specific instructions sequences are faster to
do on cn99xx compared to other cores.

Thanks,
Andrew

>

Re: [Aarch64] libmvec development status

[Szabolcs Nagy]

On 16/03/17 06:29, Sekhar, Ashwin wrote:
> Hi Glibc Team, Aarch64 Maintainers,
> 
> Could you please let us know what is the status of libmvec development for Aarch64?
> 
> Saw in this linaro talk (https://www.youtube.com/watch?v=QBOOrJnqo9A) that ARM is actively working on this. Would appreciate if you could throw some light on when we can expect this to be upstreamed.
> 

gcc-7 (in stage 4) won't have the necessary support for aarch64
libmvec so it's hard to justify the urgency, i.e. upstreaming
most likely won't happen in this glibc release cycle.
(some discussions can start earlier though.)

> Also, would appreciate if you could upstream a base code for aarch64 libmvec (need not contain any API implementations) so that it would enable others to work on target specific implementations. Would like to know your comments on the feasibility of this request.
> 

i'm not sure what target specific implementation means in this
context: i expected at most two sets of math functions for the
two aarch64 simd variants (advsimd and sve).

[Aarch64] libmvec development status

[Sekhar, Ashwin]

Hi Glibc Team, Aarch64 Maintainers,

Could you please let us know what is the status of libmvec development for Aarch64?

Saw in this linaro talk (https://www.youtube.com/watch?v=QBOOrJnqo9A) that ARM is actively working on this. Would appreciate if you could throw some light on when we can expect this to be upstreamed.

Also, would appreciate if you could upstream a base code for aarch64 libmvec (need not contain any API implementations) so that it would enable others to work on target specific implementations. Would like to know your comments on the feasibility of this request.

Thanks and Regards,
Ashwin Sekhar T K