3 ms·
Optimizing floating point calculations in this way will impact the precision of your results. Multiplying by the reciprocal will not produce the same results as
by tbirdz 11y ago
Optimizing floating point calculations in this way will impact the precision of your results. Multiplying by the reciprocal will not produce the same results as a division, especially when the error is compounded over multiple operations. Using the fpmath=fast option will also let the compiler produce faster code at the cost of accuracy.
Will this reduction in accuracy affect your application? For graphics and physics, maybe not, or at least not until some compounded error in an edge case makes a collision detection fail, or causes an unsightly visual error.
Don't just sprinkle these optimizations throughout your code without understanding the accuracy requirements of your program.
- conistonwater 11y ago> Don't just sprinkle these optimizations throughout your code without understanding the accuracy requirements of your program. There is a relatively straightforward way to think about this. Either your program depends on fully accurate error analysis (e.g. for reproducibility), or not. If yes, you would not even think of enabling fast-math, because that's implementation-defined behaviour. If no, any mathematically valid substitution will do, unless it causes some kind of unlikely numerical instability. In the case of evaluating a/x as t=1/x;a * t, it is possible to analyze the optimization exactly: without overflows, the relative error of a * (1/x) will be at most 2u/(1-u), while relative error of a/x will be at most u. Thus this substitution is absolutely fine, there's no need to be scared of it. Mathematically sensible transformations generally produce sensible results. It is exceedingly uncommon for someone to need a perfectly rounded result.