From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40164 invoked by alias); 30 Nov 2017 07:00:50 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 40149 invoked by uid 89); 30 Nov 2017 07:00:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=forgive, Hawkins, tended, hawkins X-HELO: mail-qk0-f174.google.com Received: from mail-qk0-f174.google.com (HELO mail-qk0-f174.google.com) (209.85.220.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Nov 2017 07:00:40 +0000 Received: by mail-qk0-f174.google.com with SMTP id a71so7604151qkc.9 for ; Wed, 29 Nov 2017 23:00:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nQb7p6+LdYurzfu9udWqQDHgELLAS9rva4Oq5Jxbx10=; b=JsUwMTMyjKrqbQx3mCvMXKxOslMW9wCctsgiYrVEyEj9nc4DwhmAUTFmw0Pq0JvBzu NX+QrnSrQ/qG0VJq/ChIcRh5ampORBfkagY15/lnjf7ITzrIc7T98n1fAz6mPOho8rm7 cIW+p7WJVmg+HbKdhk3t4eN5XVAP1lMKnrSqOhG9oOJNUrAeh1Tx300K4lpBx8WnWxZH FF5EN0zQrRIJynBC6za8z4WQeqfXBTZ64/yFYck7FMzm+bjcqlxhCA2ETZrB0URU6B8z BgHUd/MHp64/Ac2JM3meO5yjfhkM+HUnBkLpBwvew21XZft0cetKuUonbMzcCUAIdayq BWkg== X-Gm-Message-State: AKGB3mKkcoG8WucohOHfZgwnc7avI/PqGTGnkwujcrpucHmzVQQxb9Et RDXJESFx5uuiLnx7z7U5zXNuznSPVZu4uHSVlNs/pg== X-Google-Smtp-Source: AGs4zMbqMZ3MCqI7oFi8/7QUlTtqo5tdYqQjXcr0U5VVYuNxGdyUlsRMA9iCsdgw7ru5OGh8TemklYwfMMhB3a7wPBo= X-Received: by 10.55.27.219 with SMTP id m88mr1389552qkh.334.1512025238798; Wed, 29 Nov 2017 23:00:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.56.215 with HTTP; Wed, 29 Nov 2017 23:00:38 -0800 (PST) In-Reply-To: <20aa9deb-0a4a-91bd-fff2-79fda3a91752@redhat.com> References: <20aa9deb-0a4a-91bd-fff2-79fda3a91752@redhat.com> From: Will Hawkins Date: Thu, 30 Nov 2017 07:00:00 -0000 Message-ID: Subject: Re: Question about the highly optimized aspects of libc implementation To: "Carlos O'Donell" , siddhesh.poyarekar@gmail.com Cc: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00037.txt.bz2 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 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.