This is the mail archive of the
mailing list for the glibc project.
Re: Question about the highly optimized aspects of libc implementation
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Will Hawkins <whh8b at virginia dot edu>, libc-help at sourceware dot org
- Date: Wed, 29 Nov 2017 22:56:30 -0800
- Subject: Re: Question about the highly optimized aspects of libc implementation
- Authentication-results: sourceware.org; auth=none
- References: <CAE+MWFsT5vu4yW0zDKgyinZky=2s-i2wzK7N-fnKuQP0kGQ_Bw@mail.gmail.com>
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
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?