From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119198 invoked by alias); 9 Mar 2018 18:52:07 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 119043 invoked by uid 89); 9 Mar 2018 18:52:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=periodic, claim, millions X-HELO: mailbackend.panix.com X-Gm-Message-State: AElRT7FfX9LVVhz/YI1WAXmCVVN+9xPOPrtz27ocE0hv8Jjv/1787gYQ A05K/7Rh5g9RJ1LicVEZOCJJJTjpfMghJecvQzM= X-Google-Smtp-Source: AG47ELv0JaELaNokeOM9zS/Z3f47jE6ZQpu6nTGeF8oU6uG6m9kLo/w1pOUAVl9ij1E9tjqzxrWgS+h0rsMf8+DSl38= X-Received: by 10.202.63.85 with SMTP id m82mr20645090oia.64.1520621521504; Fri, 09 Mar 2018 10:52:01 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20180309181902.GA26430@domone> References: <8065ca77-ec8f-9925-7e9c-52266cd1e4c6@gotplt.org> <20180309181902.GA26430@domone> From: Zack Weinberg Date: Fri, 09 Mar 2018 18:52:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] Remove slow paths from sin/cos To: =?UTF-8?B?T25kxZllaiBCw61sa2E=?= Cc: Siddhesh Poyarekar , Wilco Dijkstra , "libc-alpha@sourceware.org" , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-03/txt/msg00250.txt.bz2 On Fri, Mar 9, 2018 at 1:19 PM, Ond=C5=99ej B=C3=ADlka w= rote: > On Fri, Mar 09, 2018 at 09:47:09PM +0530, Siddhesh Poyarekar wrote: >> On Friday 09 March 2018 09:16 PM, Wilco Dijkstra wrote: >> > This patch removes 2nd of the 3 range reduction cases and defer to the= final one. >> > Input values above 2^27 are extremely rare, so this case doesn't need = to as be >> > optimized as smaller inputs. >> >> Please elaborate on two more points: >> >> - The basis for your claim that values above 2^27 are extremely rare, >> i.e. papers that you may have referred that conclude this and/or >> applications you may have profiled >> > Main reason is that for these inputs accuracy doesn't make a sense. > There is already millions bigger error caused by limited precision when > rounding input to float. More concretely, for IEEE single, the gap between representable values is bigger than 2=CF=80 for values whose exponent is 2^26 or above. Since the sine function is periodic over 2=CF=80, that means the result of sinf() is effectively meaningless for any input at least that big - _any value_ within the input period could have been rounded to the representable, so the "true" answer could be anything. (I am tempted to suggest that we return NaN for inputs this large, without even bothering to do argument reduction.) For double, this happens at 2^55, and for x86-64 long double it happens at 2^66. I _think_ x86-64 long double is 80-bit IEEE extended, not quad, but I could be wrong. zw