This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: What is acceptable for -ffast-math? (Was: associative law in combine)


Gabriel Dos_reis <gdosreis@sophia.inria.fr> 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]