This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH 0/2] aarch64: Add optimized ASIMD versions of sinf/cosf
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, "adhemerval dot zanella at linaro dot org" <adhemerval dot zanella at linaro dot org>, "Ashwin dot Sekhar at cavium dot com" <Ashwin dot Sekhar at cavium dot com>
- Cc: nd <nd at arm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- Date: Tue, 13 Jun 2017 23:44:24 +0530
- Subject: Re: [RFC][PATCH 0/2] aarch64: Add optimized ASIMD versions of sinf/cosf
- Authentication-results: sourceware.org; auth=none
- References: <VI1PR0802MB2621465F621A03FFA7C4607683C20@VI1PR0802MB2621.eurprd08.prod.outlook.com>
On Tuesday 13 June 2017 11:19 PM, Wilco Dijkstra wrote:
> I don't see the point of asking him to do that. It would be a significant amount of
> work which would be wasted once Szabolcs posts his implementation.
Here's what Szabolcs said about his sinf/cosf work:
>> the plan is the next release cycle (i plan to post powf
>> first, then work on sinf/cosf, possibly sin/cos too, then
>> look at vector versions once the vector abi is in gcc).
which seems to indicate that he has not even started. I guess it is
Ashwin's call now as to whether he finds it worthwhile spending time to
work on it and then have it (probably) superseded later.
> What I'd like to ask Ashwin is which benchmarks show a speedup due to
> his patch and whether it is essential they get a speedup this release
> (rather than a larger speedup later). I don't recall seeing sinf/cosf in profiles
> in popular benchmarks, so I don't understand the urgency of doing this now.
I don't understand the point of the question. Why is an intermediate
speedup undesirable? At the very least it will help Ashwin get his
first patch into glibc, which is a great thing too since that means we
have another contributor in our fold.
> What I think would be useful is to start collecting real traces of actual applications
> or large benchmarks like SPEC and creating representative microbenchmarks
> using that data.
We had a benchmarking BoF back in 2015 and I had made notes then to help
track the long term goals we desire from such an exercise: