From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36071 invoked by alias); 30 Nov 2017 06:56:41 -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 36057 invoked by uid 89); 30 Nov 2017 06:56:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Hawkins, tended, hawkins, hand-written X-HELO: mail-qk0-f180.google.com Received: from mail-qk0-f180.google.com (HELO mail-qk0-f180.google.com) (209.85.220.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Nov 2017 06:56:39 +0000 Received: by mail-qk0-f180.google.com with SMTP id d141so7587198qkc.12 for ; Wed, 29 Nov 2017 22:56:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5aLYX/o+AD+w9YFfUaHZdHeI7iw2KjS8WKJf5Z8SiAA=; b=NRRf+YUt9Zfy56OrebX0utH+1pImOISsHjJZhKy46AwXYI6uOAAOQlw3glZDZOApFT 4Z9FV9iGYPiA1QwIWDQCdzHhGffN9RtXpzNgTmxlA5tY19bKiV5thnKbe4vs+PGjmhdB 4b1X+SiqaEfsFHMxcDfdqcfEqgD5tJpyPUEocBVUYZZGstoQkw62OtkcjfCi4kBboNud kTgzREAj1XHCUZkhsewXx5UspdrHoEuQSzjguZFMG90CkdUnDnkXv+q91ZcXwa0Qffwf 3C0TWxixJSu5nf0mQApSKwdIIeGjvu9tc6pLc0qW6D/o15KF/j1LSSwQn0XtVzVdceAT tNmg== X-Gm-Message-State: AKGB3mI0RLEp83QINkU04waPbcZo16gAZzj7sQEUu6TEdiS9tTJRtxLR lyqX91jl8gLLkORJ8OA6xncKYXidPfY= X-Google-Smtp-Source: AGs4zMbyAWJcfDE8AciU5zIYN3gYiY8tOeAaiXO5yTl/KRmx1GCm+T8YCFooUvUE9kCa2Poffo1NuA== X-Received: by 10.55.146.65 with SMTP id u62mr1341265qkd.358.1512024997737; Wed, 29 Nov 2017 22:56:37 -0800 (PST) Received: from [10.150.73.190] ([184.151.231.222]) by smtp.gmail.com with ESMTPSA id q191sm2542842qke.54.2017.11.29.22.56.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 22:56:36 -0800 (PST) Subject: Re: Question about the highly optimized aspects of libc implementation To: Will Hawkins , libc-help@sourceware.org References: From: Carlos O'Donell Message-ID: <20aa9deb-0a4a-91bd-fff2-79fda3a91752@redhat.com> Date: Thu, 30 Nov 2017 06:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00036.txt.bz2 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.