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] powerpc: Add a POWER8-optimized version of powf()


On 05/27/2017 07:55 AM, Wilco Dijkstra wrote:
> Steven Munroe wrote:
>> On Fri, 2017-05-26 at 16:55 -0300, Adhemerval Zanella wrote:
>> > This changes seems to be arch independent and I would like to avoid adding
>> > even more arch specific.  Is there any reason why this can't be used as
>> > the default implementation?  Do you have number on different architecture
>> > for it? 
>> > 
>> If other platform maintainer what to try this implementation and report
>> that would be OK. 
>>
>> But I don't this it is correct or fair to ask Paul to prove a negative.
>> These quests tend to be very labor intensive and usually don't work out
>> (as really common) in the end.
> 
> I disagree. We've seen time and time again that well-written generic code beats target
> specific code. So I would suggest to focus on improving the algorithms in generic code
> rather than do target specific hacks that don't turn out to be useful in the long run.
> This will not only result in more efficient code, but it is also far cheaper in development
> time as it only needs to be done once and can be shared across all targets.

I'm not easily able to test and validate performance on other platforms.  I'm not sure the maintainers of those other platforms would want me to, anyway.

I do understand the motivation to encourage architecture-agnostic code in lieu of architecture-specific.

How about making it fairly trivial to share the code, by dropping it in a common place, like /sysdeps/generic or /sysdeps/wordsize-64 or /sysdeps/ieee754?  Other arches can then easily include it without having to copy it or include it from a foreign arch directory, when and if they wish.

This seems like an issue that would be commonly encountered.  Are there generally recommended practices?

> For this function I can't see why you'd ever want an ifunc unless there are cases where 
> it doesn't beat the default powf implementation (presumably due to using 2 double 
> precision divisions?).

That may be, and it would simplify the implementation let me look at removing the IFUNC part.

> As it happens Szabolcs wrote a prototype powf that is not only
> more accurate but also 4x faster, all using generic code. With these gains, target
> specific math functions will be obsolete...

Is that forthcoming?

Regards,
PC


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