Optimizations Enabled by -ffast-Math
kristerw.github.io
Optimizations Enabled by -ffast-Math
1–10 of 117 posts
Re: Optimizations Enabled by -ffast-Math
#2The question is how to enable all this in Rust... Right now there's no simple way to just tell Rust to be fast & loose with floats.
Re: Optimizations Enabled by -ffast-Math
#3The question is how to enable all this in Rust... Right now there's no simple way to just tell Rust to be fast & loose with floats.
Rust is not really a fast & loose language where anything can be UB.
At least it doesn't need the errno ones since rust don't use errno.
Re: Optimizations Enabled by -ffast-Math
#4The question is how to enable all this in Rust... Right now there's no simple way to just tell Rust to be fast & loose with floats.
It must be clearly understood which of the flags are entirely safe and which need to be under 'unsafe', as a prerequisite.
Blanket flags for the whole program do not fit very well with Rust, while point use of these flags is inconvenient or needs new syntax.. but there are discussions about these topics.
Re: Optimizations Enabled by -ffast-Math
#5Do some applications actually use denormal floats ? I'm curious.
Re: Optimizations Enabled by -ffast-Math
#6Do some applications actually use denormal floats ? I'm curious.
Accidentally trigger that path now and then? Probably. Depends on subnormals to give a reasonable result? Probably rare. But what do I know...
Re: Optimizations Enabled by -ffast-Math
#7Do some applications actually use denormal floats ? I'm curious.
Denormal floats are not a purpose, they are not used intentionally.
When the CPU generates denormal floats on underflow, that ensures that underflow does not matter, because the errors remain the same as at any other floating-point operation.
Without denormal floats, underflow must be an exception condition that must be handled somehow by the program, because otherwise the computation errors can be much higher than expected.
Enabling flush-to-zero instead is an optimization of the same kind as ignoring integer overflow.
It can be harmless in a game or graphic application where a human will not care if the displayed image has some errors, but it can be catastrophic in a simulation program that is expected to provide reliable results.
Providing a flush-to-zero option is a lazy solution for CPU designers, because there have been many examples in the past of CPU designs where denormal numbers were handled without penalties for the user (but of course with a slightly higher cost for the manufacturer) so there was no need for a flush-to-zero option.
Re: Optimizations Enabled by -ffast-Math
#8The question is how to enable all this in Rust... Right now there's no simple way to just tell Rust to be fast & loose with floats.
It must be clearly understood which of the flags are entirely safe and which need to be under 'unsafe', as a prerequisite. Blanket flags for the whole program do not fit very well with Rust, while point use of these flags is inconvenient or needs new syntax.. but there are discussions about these topics.
Also maybe you woild like to have more granular control over which parts of your program has the priority on speed and which part favours accuracy. Maybe this could be done with a seperate type (e.g. ff64) or a decorator (which would be useful if you want to enable this for someone elses library).
Re: Optimizations Enabled by -ffast-Math
#9Do some applications actually use denormal floats ? I'm curious.
It's not that you decide specifically to use them, but sometimes they sort of happen very naturally. For example, if you evaluate a Gaussian function f(x)=e^(-x^2), for moderate values of x the value f(x) is denormal.
Re: Optimizations Enabled by -ffast-Math
#10Earlier quoted context omitted.
It must be clearly understood which of the flags are entirely safe and which need to be under 'unsafe', as a prerequisite. Blanket flags for the whole program do not fit very well with Rust, while point use of these flags is inconvenient or needs new syntax.. but there are discussions about these topics.
Also maybe you woild like to have more granular control over which parts of your program has the priority on speed and which part favours accuracy. Maybe this could be done with a seperate type (e.g. ff64) or a decorator (which would be useful if you want to enable this for someone elses library).
Maybe... or maybe there would be just a flag to enable all this and be fine with consequences.