What are the drawbacks of the Release - Fast FPU build?

MasterGod · Post by **MasterGod** » Mon Mar 31, 2008 11:15 am

I've been wondering, what drawbacks does the "Release - Fast FPU" has because I guess if it hadn't there would be only Debug and that..

Thanks.

hybrid · Post by **hybrid** » Mon Mar 31, 2008 11:21 am

It might give you imprecise results.

MasterGod · Post by **MasterGod** » Mon Mar 31, 2008 11:52 am

hybrid wrote:It might give you imprecise results.

Can you explain me maybe, why?

Which configuration causes the impreciseness. (what a word

)

bitplane · Post by **bitplane** » Mon Mar 31, 2008 7:05 pm

see microsoft's article on this-
http://msdn2.microsoft.com/en-us/library/e7s85ffb.aspx

msdn wrote:By default, the compiler uses the coprocessor's 80-bit registers to hold the intermediate results of floating-point calculations. This increases program speed and decreases program size. Because the calculation involves floating-point data types that are represented in memory by less than 80 bits, however, carrying the extra bits of precision (80 bits minus the number of bits in a smaller floating-point type) through a lengthy calculation can produce inconsistent results.

(my emphasis)

So we're talking low level compiler optimizations that do not conform to the IEEE float standard, but are faster. Also see /Oi
http://msdn2.microsoft.com/en-us/library/f99tchzc.aspx

msdn wrote:x86 Specific

The intrinsic floating-point functions do not perform any special checks on input values and so work in restricted ranges of input, and have different exception handling and boundary conditions than the library routines with the same name. Using the true intrinsic forms implies loss of IEEE exception handling, and loss of _matherr and errno functionality; the latter implies loss of ANSI conformance. However, the intrinsic forms can considerably speed up floating-point-intensive programs, and for many programs, the conformance issues are of little practical value.

MasterGod · Post by **MasterGod** » Mon Mar 31, 2008 8:04 pm

Thanks.

BlindSide · Post by **BlindSide** » Mon Mar 31, 2008 9:03 pm

So it's not necessarily that much less precision, but no error handling/standard conformance? Sweet, gotta try this... (BlindSide is all for the non-conformance

)

Castaa · Post by **Castaa** » Fri Aug 22, 2008 4:08 am

The info posted here is great. Thank you.

Does anyone have some experiences to how much this configuration (Fast FPU) improve an Irrlicht graphics intensive application?

joshcryer · Post by **joshcryer** » Wed Dec 17, 2008 8:34 am

This question came up on IRC and I found this post on Google. I'm also wondering if anyone did any benchmarks or whether or not this actually has a perceptable benefit. I didn't notice it in my software.

rogerborg · Post by **rogerborg** » Wed Dec 17, 2008 11:05 am

Any benefits will be application dependent. I'm wondering whether we should just remove the 'fast' targets, since anyone who knows enough about the implications to make an informed decision to use them could trivially do their own build with /fp:fast or -ffast-math if they want.