From owner-freebsd-i386@FreeBSD.ORG Sun Feb 13 19:38:21 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8761016A4CE; Sun, 13 Feb 2005 19:38:21 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id D202843D5A; Sun, 13 Feb 2005 19:38:20 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j1DJcJA6019340; Mon, 14 Feb 2005 06:38:19 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j1DJcHGg014032; Mon, 14 Feb 2005 06:38:17 +1100 Date: Mon, 14 Feb 2005 06:38:16 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20050213180837.GA70513@VARK.MIT.EDU> Message-ID: <20050214062033.M40410@delplex.bde.org> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> <20050209051401.GA18775@VARK.MIT.EDU> <20050209232758.F3249@epsplex.bde.org> <20050210072314.GA26713@VARK.MIT.EDU> <20050214000320.U1866@epsplex.bde.org> <20050213180837.GA70513@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-gnats-submit@FreeBSD.org cc: freebsd-i386@FreeBSD.org cc: bde@FreeBSD.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 19:38:21 -0000 On Sun, 13 Feb 2005, David Schultz wrote: > On Mon, Feb 14, 2005, Bruce Evans wrote: > > >... > > I did a quick test of some other functions: > > - hardware sqrt is much faster > > - hardware exp is slightly faster on the range [1,100] > > - hardware atan is slower on the range [0,1.5] > > - hardware acos is much slower (139 nsec vs 57 nsec!) on the range [0,1.0]. > > sqrt isn't transcendental, so it should be faster and correctly > rounded on every hardware platform. I found similar results to I don't know if we can trust the hardware for that. ISTR checking that hardware sqrtf gives the same result as fdlibm for possible values for sqrtf. This is of course impossible for double sqrt. > yours for atan() and acos() when writing amd64 math routines, but > of course amd64 has the overhead of switching between the SSE and > i387 units. Maybe they should go away, too... These are easier to decide (for now) because there are no old CPUs. I fixed the bug that gave unbelievable cycle counts: %%% --- r.c~ Mon Feb 14 02:19:34 2005 +++ r.c Mon Feb 14 02:22:21 2005 @@ -45,4 +47,5 @@ tmax = 0; tmin = INT_MAX; + total = 0; for (i = 0; i < ITER; i++) { if (fabs(avg - t[i]) <= sd * 2) { %%% With this fix on athlon-xp's, the cpuid instructions only disturb the cycle counts in a small and almost deterministic way (by about 59 cycles for every run). Bruce