3 ms·

> I mean, the whole point of fast-math is trading off speed with correctness. If fast-math was to give always the correct results, it wouldn’t be fast-math, it

by rlpb 1y ago

> I mean, the whole point of fast-math is trading off speed with correctness. If fast-math was to give always the correct results, it wouldn’t be fast-math, it would be the standard way of doing math. A similar warning applies to -O3. If an optimization in -O3 were to reliably always give better results, it wouldn't be in -O3; it'd be in -O2. So blindly compiling with -O3 also doesn't seem like a great idea.

CamouflagedKiwi 1y ago
The optimisations in -O3 aren't supposed to give incorrect results. They're not in -O2 because they make a more aggressive space/speed tradeoff or increase compile times more significantly. In the same way, the optimisations in -O2 are not meant to be less correct than -O1, but they aren't in that group for similar reasons. -Ofast is the 'dangerous' one. (It includes -ffast-math).
- rlpb 1y ago
  > The optimisations in -O3 aren't supposed to give incorrect results. I didn't mean to imply that they result in incorrect results. > they make a more aggressive space/speed tradeoff... Right...so "better" becomes subjective, depends on the use case, so it doesn't make sense to choose -O3 blindly unless you understand the trade-offs and want that side of them for the particular builds you're doing. Things that everyone wants would be in -O2. That's all I'm saying.
  - eqvinox 1y ago
    It doesn't become subjective; things in -O3 can objectively be understood to produce equal or faster code for a higher build cost in the vast majority of cases, roughly averaged across platforms. (Without loss in correctness.) If you know your exact target and details about your input expectations, of course you can optimize further, which might involve turning off some things in -O3 (or even -O2). On a whole bunch of systems, -Os can be faster than -O3 due to I-cache size limits. But at-large, you can expect -O3 to be faster. Similar considerations apply for LTO and PGO. LTO is commonly default for release builds these days, it just costs a whole lot of compile time. PGO is done when possible (i.e. known majority inputs).
  - CamouflagedKiwi 1y ago
    If they're things that everyone wants, why aren't they in -O1?
    - rlpb 1y ago
      -O1 is defined not to perform "any optimizations that take a great deal of compilation time". See the definitions in the manpage.
      - CamouflagedKiwi 1y ago
        Yes, exactly my point. Things in -O2 but not -O1 are hence not "things that everyone wants".
wffurr 1y ago
If the answer can be wrong, you can make it as fast as you want.
- zzo38computer 1y ago
  It depend what kind of wrong answers are acceptable (and in what circumstances).

by rlpb 1y ago

CamouflagedKiwi 1y ago

The optimisations in -O3 aren't supposed to give incorrect results. They're not in -O2 because they make a more aggressive space/speed tradeoff or increase compile times more significantly. In the same way, the optimisations in -O2 are not meant to be less correct than -O1, but they aren't in that group for similar reasons. -Ofast is the 'dangerous' one. (It includes -ffast-math).

rlpb 1y ago
> The optimisations in -O3 aren't supposed to give incorrect results. I didn't mean to imply that they result in incorrect results. > they make a more aggressive space/speed tradeoff... Right...so "better" becomes subjective, depends on the use case, so it doesn't make sense to choose -O3 blindly unless you understand the trade-offs and want that side of them for the particular builds you're doing. Things that everyone wants would be in -O2. That's all I'm saying.
- eqvinox 1y ago
  It doesn't become subjective; things in -O3 can objectively be understood to produce equal or faster code for a higher build cost in the vast majority of cases, roughly averaged across platforms. (Without loss in correctness.) If you know your exact target and details about your input expectations, of course you can optimize further, which might involve turning off some things in -O3 (or even -O2). On a whole bunch of systems, -Os can be faster than -O3 due to I-cache size limits. But at-large, you can expect -O3 to be faster. Similar considerations apply for LTO and PGO. LTO is commonly default for release builds these days, it just costs a whole lot of compile time. PGO is done when possible (i.e. known majority inputs).
- CamouflagedKiwi 1y ago
  If they're things that everyone wants, why aren't they in -O1?
  - rlpb 1y ago
    -O1 is defined not to perform "any optimizations that take a great deal of compilation time". See the definitions in the manpage.
    - CamouflagedKiwi 1y ago
      Yes, exactly my point. Things in -O2 but not -O1 are hence not "things that everyone wants".

wffurr 1y ago

If the answer can be wrong, you can make it as fast as you want.

zzo38computer 1y ago
It depend what kind of wrong answers are acceptable (and in what circumstances).