Re: Question about the highly optimized aspects of libc implementation

[Will Hawkins <whh8b at virginia dot edu>]

Mr. O' Donell and Poyarekar,

Forgive the top-posting but I just wanted to quickly thank both of
your for your answers! This is exactly the type of information that I
was hoping to gather. Thank you again!

Will

On Thu, Nov 30, 2017 at 1:56 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 11/29/2017 10:47 PM, Will Hawkins wrote:
>> I've been digging through the glibc implementation and looking for
>> examples of where compiler directives or hand-written assembly have
>> been used to improve performance at the "expense" of standards or
>> conventions.
>
> Let me address the "standards" side of this...
>
> No such thing exists and has a public interface that conforming programs
> can call. Such things may exist internal to glibc, but then we have
> control over the API/ABI and can do what we want.
>
> We have some functions which have standards for them, but for which
> we don't follow the standard because Linux did it one way and
> that's the only supportable way e.g. group scheduling etc.
>
> Let me address the "conventions" side of this...
>
> The entire math library has "cheats" which would be assembly implementations
> that have lower accuracy bounds. We have generally tended to remove these
> since we want a certain uniform level of accuracy for all the math functions
> where possible. One example was the removal of x86 sincos hardware support
> for the generic sin/cos support because the x86 hardware version is not
> accurate enough (poor range reduction).
>
> Does that answer your question?
>
> --
> Cheers,
> Carlos.