4 ms·

-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 o

by nsajko 4y ago

-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.

actually_a_dog 4y ago
I agree. I think --ffast-math should actually be called --finexact-math. One would also hope that explicitly disabling an option on the command line would, you know, explicitly disable the option, but maybe that's too much to ask.
- mbauman 4y ago
  I don't think it should exist at all. It's such a crazy grab bag of code changes disguised as "optimizations" that it's completely impossible to reason about, even for folks that "don't care" about the exact floating point arithmetic. It has global effects like those in TFA, and even locally you no longer know if a line or two of arithmetic will become more precise (e.g., by using higher precision intermediate results), less precise, or become complete gibberish (e.g., because it thinks it can prove you're now dividing by zero and thus can just return whatever it wants).
- trelane 4y ago
  -fyolo-math? -fgoodenough-math? -fbroken-but-fast-math
mbauman 4y ago
I wholeheartedly disagree. -Ofast Disregard strict standards compliance. ... There's strict standards compliance and then there's the crazy grab bag of code changes that is `-ffast-math`. Further, I'd say gevent can defensibly say that -ffast-math is okay for them given what the manual says: -ffast-math ... it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. This is 100% on the compiler people. For the option name, the documentation, and the behavior. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Options.html#Optimize-Options https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Optio...
- nsajko 4y ago
  Well, how would you improve the docs? Both documentation entries seem reasonable to me. That said, I don't see why the -Ofast option even needs to exist, except backwards compatibility, as -ffast-math and the others can (and should IMO) be specified explicitly.
  - mrguyorama 4y ago
    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.
    - nsajko 4y ago
      > 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 people here act like the docs say "translation unit" or something like that, instead of "program", but this is simply not the case. Furthermore, the entry for -ffast-math points to entries for suboptions that -ffast-math turns on (located right below in the man page), e.g. -funsafe-math-optimization. These also make clear how dangerous they can be even when turned on one at a time.
      - tomrod 4y ago
        How many programs do you deal with daily that you don't anticipate to follow ISO/IEEE?
        account42 4y ago
bombcar 4y ago
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.
- cesarb 4y ago
  > It's hard to come up with a similar name that isn't long. The suggestion given elsewhere in these comments to call it "unsafe math" instead of "fast math" sounds good. It's nearly as short, and properly conveys the "you must know what you're doing" aspect of these flags. It's even better if you're used to Rust.
- tomrod 4y ago
  "-Wslightly-broken-but-swift"
fweimer 4y ago
What's missing is that it also affects linking, and results in this strange action-at-a-distance. Maybe disabling the linker part with -shared would be a reasonable compromise.
- nsajko 4y ago
  You're wrong, both the doc entry for -Ofast and the one for -ffast-math say that they can result in incorrect programs. Programs are produced by linking, so I don't see what other way to interpret this is possible.
  - brigade 4y ago
    Why not simply replace all FP math with a constant zero? That’d be really fast and an equally valid strict interpretation of “can result in incorrect programs.”
    - nsajko 4y ago
      See https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html, e.g.: > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
      - brigade 4y ago
        Just because you’re shallowly dismissing my comment doesn’t make it wrong. Linking in code with undefined (in this case, redefined) behavior doesn’t automatically invalidate the entire program. But thats the language used because once the undefined behavior is hit at runtime, the spec no longer defines what the behavior is and what the program will do afterwards.
astrange 4y ago
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.
- pixl97 4y ago
  -ffast-death -fcorrupt-quietly

by nsajko 4y ago

actually_a_dog 4y ago

I agree. I think --ffast-math should actually be called --finexact-math. One would also hope that explicitly disabling an option on the command line would, you know, explicitly disable the option, but maybe that's too much to ask.

mbauman 4y ago
I don't think it should exist at all. It's such a crazy grab bag of code changes disguised as "optimizations" that it's completely impossible to reason about, even for folks that "don't care" about the exact floating point arithmetic. It has global effects like those in TFA, and even locally you no longer know if a line or two of arithmetic will become more precise (e.g., by using higher precision intermediate results), less precise, or become complete gibberish (e.g., because it thinks it can prove you're now dividing by zero and thus can just return whatever it wants).
trelane 4y ago
-fyolo-math? -fgoodenough-math? -fbroken-but-fast-math

mbauman 4y ago

I wholeheartedly disagree. -Ofast Disregard strict standards compliance. ... There's strict standards compliance and then there's the crazy grab bag of code changes that is `-ffast-math`. Further, I'd say gevent can defensibly say that -ffast-math is okay for them given what the manual says: -ffast-math ... it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. This is 100% on the compiler people. For the option name, the documentation, and the behavior. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Options.html#Optimize-Options https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Optio...

nsajko 4y ago
Well, how would you improve the docs? Both documentation entries seem reasonable to me. That said, I don't see why the -Ofast option even needs to exist, except backwards compatibility, as -ffast-math and the others can (and should IMO) be specified explicitly.
- mrguyorama 4y ago
  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.
  - nsajko 4y ago
    > 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 people here act like the docs say "translation unit" or something like that, instead of "program", but this is simply not the case. Furthermore, the entry for -ffast-math points to entries for suboptions that -ffast-math turns on (located right below in the man page), e.g. -funsafe-math-optimization. These also make clear how dangerous they can be even when turned on one at a time.
    - tomrod 4y ago
      How many programs do you deal with daily that you don't anticipate to follow ISO/IEEE?
      - account42 4y ago

bombcar 4y ago

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.

cesarb 4y ago
> It's hard to come up with a similar name that isn't long. The suggestion given elsewhere in these comments to call it "unsafe math" instead of "fast math" sounds good. It's nearly as short, and properly conveys the "you must know what you're doing" aspect of these flags. It's even better if you're used to Rust.
tomrod 4y ago
"-Wslightly-broken-but-swift"

fweimer 4y ago

What's missing is that it also affects linking, and results in this strange action-at-a-distance. Maybe disabling the linker part with -shared would be a reasonable compromise.

nsajko 4y ago
You're wrong, both the doc entry for -Ofast and the one for -ffast-math say that they can result in incorrect programs. Programs are produced by linking, so I don't see what other way to interpret this is possible.
- brigade 4y ago
  Why not simply replace all FP math with a constant zero? That’d be really fast and an equally valid strict interpretation of “can result in incorrect programs.”
  - nsajko 4y ago
    See https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html, e.g.: > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
    - brigade 4y ago
      Just because you’re shallowly dismissing my comment doesn’t make it wrong. Linking in code with undefined (in this case, redefined) behavior doesn’t automatically invalidate the entire program. But thats the language used because once the undefined behavior is hit at runtime, the spec no longer defines what the behavior is and what the program will do afterwards.

astrange 4y ago

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.

pixl97 4y ago
-ffast-death -fcorrupt-quietly