From owner-freebsd-numerics@FreeBSD.ORG Sun Jan 4 12:47:03 2015 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E703EBB; Sun, 4 Jan 2015 12:47:03 +0000 (UTC) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3FF1C12E2; Sun, 4 Jan 2015 12:47:03 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id E9F6ED41DCC; Sun, 4 Jan 2015 23:46:53 +1100 (AEDT) Date: Sun, 4 Jan 2015 23:46:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pedro Giffuni Subject: Re: glibc math improvements In-Reply-To: Message-ID: <20150104233859.P1781@besplex.bde.org> References: <884D1A4A-76B7-4E7B-939A-6FD7D6D6D18D@freebsd.org> <20150104043745.GA79370@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R8o6R7hX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=20KFwNOVAAAA:8 a=ZN1U5jtrOG6xIs0MbFgA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-numerics@freebsd.org, Steve Kargl X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 12:47:03 -0000 On Sun, 4 Jan 2015, Pedro Giffuni wrote: > >> Il giorno 03/gen/2015, alle ore 23:37, Steve Kargl ha scritto: >> >> On Sat, Jan 03, 2015 at 10:00:58PM -0500, Pedro Giffuni wrote: >>> >>> This blog post was covered by Phoronix: >>> http://developerblog.redhat.com/2015/01/02/improving-math-performance-in-glibc/ >>> >>> Not sure any of that stuff is applicable to our implementation but it looks like an interesting link to share nevertheless. >>> >> >> AFAICT, it is not applicable. The improvements are in >> a 768-bit multi-precision computation of pow() to get an >> accurate answer. The article mentions that the technique >> may be applied to exp() and log(), but the table-driven >> methods that Bruce, David, and I used for logl, expl, and >> exp2l are quite accurate (somewhere around ulp < 0.55 or so). > > OK, I see, apparently the improvements only apply for worst-case > scenarios but we never hit them. 768 bits is a lot. Expect a slowness factor of a few hundred. We use at most 64 extra bits in exp() and log() and work hard to make the slowness factor closer to 1 than 2. pow() has more worst cases than exp() and log(), but 768 bits for it seems excessive. Maybe that is needed for perfect rounding. sin(x) needs only about 64 bits for for perfect rounding after its arg is reduced, but the arg reduction step requires almost 20000 bits in the worst case. We don't attempt to do perfect rounding. Bruce