91–100 of 132 posts
Though they use the term denormalized, which AFAICT is the a synonym for subnormal.
Edit: Thanks for this great blogpost :)
Earlier quoted context omitted.
Anyway, since there aren't any dependencies between a, b, c, and d, I would expect the two divisions to end up basically in parallel in the pipeline. So the critical path is a division and a multiplication either way. Of course that is just a guess.
That assumes you can do multiple divisions in parallel. Back in the good old days, a single division unit was the norm, and it still is on most microcontrollers (assuming they even have hardware floating-point division[1]). Anyone have any references on how the current state of affairs on modern AMD/Intels? [1]: ARM Cortex-M4 for example can have a hardware FPU, but where division and sqrt are optional, see https://d…
Use of fast math can really really really bite you sometimes, so just being able to opt into using fma and nothing else is awesome.
Denormalized numbers is one reason why you really want to think carefully if you try to optimize code by rewriting expressions involving multiplication and division. For example, if you got "x = (a / b) * (c / d)" one might think that rewriting it as "x = (a * c) / (b * d)" will save you a division and gain you speed. It will and it might, respectively. However it will also potentially break an otherwise safe operati…
Earlier quoted context omitted.
The fact that -ffast-math makes no mention that it will poison any other code executing in your process space is a huge missing point of info. Docs as written, anyone not doing scientific math should have that flag, but the reality is that most people have some code somewhere in their process that expects fairly sane floating point math behavior, even if it's just displaying progress bars or something.
> The fact that -ffast-math makes no mention that it will poison any other code executing in your process space Untrue. The doc entry for -ffast-math says "can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions". Emphasis mine. So they clearly say that the entire program can turn invalid when -ffast-math is used. You and some other peo…
-Ofast isn't a good name for the option, but in GCC's defense the manual is pretty clear about all this, and there's no excuse for blindly turning on compiler options - they literally change the semantics of your code.
It's a quirk of language, that for compiler writers and other algorithmic people "fast" often means "ballpark, but damn quick". It's hard to come up with a similar name that isn't long.
Denormalized numbers is one reason why you really want to think carefully if you try to optimize code by rewriting expressions involving multiplication and division. For example, if you got "x = (a / b) * (c / d)" one might think that rewriting it as "x = (a * c) / (b * d)" will save you a division and gain you speed. It will and it might, respectively. However it will also potentially break an otherwise safe operati…
In D you can opt into specific float algorithms locally rather than a compiler flag. Use of fast math can really really really bite you sometimes, so just being able to opt into using fma and nothing else is awesome.
Earlier quoted context omitted.
The fact that -ffast-math makes no mention that it will poison any other code executing in your process space is a huge missing point of info. Docs as written, anyone not doing scientific math should have that flag, but the reality is that most people have some code somewhere in their process that expects fairly sane floating point math behavior, even if it's just displaying progress bars or something.
> The fact that -ffast-math makes no mention that it will poison any other code executing in your process space Untrue. The doc entry for -ffast-math says "can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions". Emphasis mine. So they clearly say that the entire program can turn invalid when -ffast-math is used. You and some other peo…
They: Sir, that is dash F unsafe!
-Ofast isn't a good name for the option, but in GCC's defense the manual is pretty clear about all this, and there's no excuse for blindly turning on compiler options - they literally change the semantics of your code.
Naming options (or methods or projects) "fast" or "faster" is dangerous; either they're broken, or some day they'll turn out to not be fast anymore. IIRC Swift changed -Ofast to -Ounchecked after I complained about it.
-fcorrupt-quietly