From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18811 invoked by alias); 23 Dec 2011 20:11:15 -0000 Received: (qmail 18802 invoked by uid 22791); 23 Dec 2011 20:11:13 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from jlefevre.net1.nerim.net (HELO smtp-xvii.vinc17.net) (80.65.226.245) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Dec 2011 20:10:59 +0000 Received: by xvii.vinc17.org (Postfix, from userid 1000) id 2F2BA310066; Fri, 23 Dec 2011 21:10:57 +0100 (CET) Date: Fri, 23 Dec 2011 20:25:00 -0000 From: Vincent Lefevre To: Segher Boessenkool Cc: Dario Saccavino , Jonathan Wakely , Ico , gcc-help Subject: Re: Floating point performance issue Message-ID: <20111223201057.GB15484@xvii.vinc17.org> Mail-Followup-To: Segher Boessenkool , Dario Saccavino , Jonathan Wakely , Ico , gcc-help References: <20111220112357.GC3072@xvii.vinc17.org> <20111220120157.GD3072@xvii.vinc17.org> <255C6DEC-2FE5-4346-8C16-B8098DD3B248@kernel.crashing.org> <20111220124303.GE3072@xvii.vinc17.org> <82A73066-4874-42C1-A0BC-F1A59E9E0665@kernel.crashing.org> <20111220201600.GI3072@xvii.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.21-6200-vl-r48020 (2011-12-03) X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg00220.txt.bz2 On 2011-12-21 05:35:53 +0100, Segher Boessenkool wrote: > ...And then, of course, I discover the program does not calculate > f**(2*S) but f**(2*S-1). Which makes my "correct" results not so > very correct. Ouch. > > >It outputs: > > > >nearest = 0.36787944637187158792 > >down = 0.36787944526181193261 > > > >while we have > > correct = 0.36787944576993540330 > > so both rounding modes are about equal. > > >Now you can say that this is because x already is rounded from the > >true value, > > ... and this is indeed ... > > >the case: taking S=2**25, we get > > > >nearest = 0.36787944391225085860 > >down = 0.36787944204965455918 > > > >with > > correct = 0.36787944391235777181 > > so in that case round towards zero gets twice as many bits > wrong as round to nearest, just as a naive analysis would show. and ideally, you should test programs on many inputs, and also prove error bounds (which will probably be pessimistic, but guaranteed). Now, what I wanted to say is that in general, leaving the rounding to nearest and setting FTZ would be much better than changing the rounding mode globally. Another drawback of changing the rounding mode globally is that some libraries may not support it; this is the case of the math library from the glibc on x86_64 (and other processors for which the same code is used): http://sourceware.org/bugzilla/show_bug.cgi?id=3976 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)