From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Ing-Simmons To: gdosreis@sophia.inria.fr Cc: tim@hollebeek.com, Gabriel Dos_Reis , Theodore Papadopoulo , gcc@gcc.gnu.org, Wolfgang Bangerth Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine) Date: Fri, 03 Aug 2001 07:32:00 -0000 Message-id: <20010803143140.16603.4@bactrian.ni-s.u-net.com> References: <15208.17962.179912.327778@perceval.inria.fr> <200108011827.f71IRBI09980@mururoa.inria.fr> <15208.20087.735621.976700@perceval.inria.fr> X-SW-Source: 2001-08/msg00174.html Gabriel Dos_reis writes: >| Gabriel.Dos_Reis@sophia.inria.fr said: >| > | and probably a whole lot of other things that are equally "dubious". >| > | | | > But then, if they would have written that form in the first >| > place. | | But, as I said, there might be cases where you can't write >| > it in an | optimized way in the first place, such as in | inline >| > double f() { return a/b; } | inline double g() { return c; } | x >| > = f()/g(); | plus inlining. >| >| > But then is 0.0 is acceptable for 0.125 for speed? >| >| Yes, if you know by advance that this cannot happen because of your >| input data accuracy. Then you will get the speed advantage without >| the loss of accuracy since it cannot happen. > >Data for the supposed speed in such case are still missing. Divide is very slow compared to multiply in modern hardware. r = a/(b*c) has one divide r = a/b/c has two. Divide also seldom pipelines as well. In real-time image processing (say) failing to compute the frame in 20mS is catastrophic, but having a pixel black (0.0) rather than 0.125 white (Dark gray) is of minimal impact. > >-- Gaby -- Nick Ing-Simmons http://www.ni-s.u-net.com/