This is the mail archive of the 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: Question about the highly optimized aspects of libc implementation

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!


On Thu, Nov 30, 2017 at 1:56 AM, Carlos O'Donell <> 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.

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