Announcement

Collapse
No announcement yet.

Proposal Raised To Deprecate "-Ofast" For The LLVM/Clang Compiler

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • User42
    replied
    Originally posted by aviallon View Post

    You just have to replace -Ofast with -O3 -ffast-math, and you're done.
    And break a large amount of scripts out there and making things incompatible with GCC in that niche.

    And all that for what reason? Because some people don't read the doc? If there was a technical solution to stupidity, it would have been implemented a long time ago.

    I fully understand that you don't see the problem because the solution looks simple. However such a change will translate to thousands of tickets and bug reports because "compilation fails" or "my script does not work" or "my docker compose broke". If there was any gain at all, there's a discussion to be had; when it's for dubious reasons, it's just breaking things for pleasure.

    Leave a comment:


  • ms178
    replied
    Originally posted by aviallon View Post

    It already exists (genetic algorithms for automatic flag selection), but it is _super_ slow, and you must have a good synthetic benchmark with it too (as if you were doing PGO, but with a hundred more steps).
    Thanks for letting me know, in researching this topic further I stumbled upon this Arxiv paper. Hopefully the proposed AI autotuning will become a reality soon.

    Leave a comment:


  • archkde
    replied
    Good, we don't need a "break my program in interesting ways" option that sounds like a good thing. If you really want non-compliant math, just use -ffast-math yourself (which should probably be called -funsafe-fast-math itself…), and don't get shit like -fallow-store-data-races with GCC at least.

    Leave a comment:


  • indepe
    replied
    Originally posted by aviallon View Post

    You just have to replace -Ofast with -O3 -ffast-math, and you're done.
    The proponents of the change didn't seem to know (or silently ignored) that -Ofast enables/disables more options than just -ffast-math, at least on GCC.

    Which makes me wonder if they are really looking at the whole situation. Personally I haven't used -Ofast _yet_, however I'd expect this option is used by many who know what they are doing, and have determined that their software really doesn't need to be super compliant. I don't think it is necessarily a good strategy to break behavior for those who know what they do in favor of those who don't.

    Plus it sounds more like guessing that there is a problem than really knowing how large it is. The proponents "think" there is a problem related to something called "my experience" of knowledge about the option's meaning. What does that mean? Is there a real problem resulting for them, or just an unspecified number of people who don't know what the option does exactly?

    Leave a comment:


  • Weasel
    replied
    LLVM proving why it's a joke as always.

    Leave a comment:


  • ctbr
    replied
    My perception is there was some history here...
    • Earlier versions of SPEC CPU such as CPU 2000 had a set of run rules including 2.2.6 which limited the number of base options that could be used. This rule was later removed in CPU 2006 run rules.
    • One way of addressing this limit was added to the Intel compiler, "-fast" which was a shorthand for a combination of optimizations including some that met numerical guidelines from language standards at the time even if not fully IEEE 754 compliant.
    • gcc added -Ofast after -fast was already in the Intel compiler. gcc documents the set of optimizations that are performed as part of -Ofast. It includes a statement that these optimizations may not be fully standards compliant
    • llvm adds -Ofast after -Ofast was also in gcc. This seems to focus mostly on the -fast-math subset of unsafe optimizations - though Intel and gcc compilers had optimizations beyond -fast-math
    Now llvm has this discussion on deprecating -Ofast as an option.

    Leave a comment:


  • aviallon
    replied
    Originally posted by ms178 View Post

    Sure, that is another simple solution and I understand the reasoning behind it. The problem is that I don't want to leave any performance on the table and a large number of users are in the same boat that don't know about the details of the code base nor do users know if the devs care about Ofast or performance at all. My current practice is to follow what Clear Linux does or test it out experimentally on a package-by-package basis. I think this could be improved further, my dream would be to have an AI optimizing the source code to the machine where the code is executed, creating optimal code for the specific target.
    It already exists (genetic algorithms for automatic flag selection), but it is _super_ slow, and you must have a good synthetic benchmark with it too (as if you were doing PGO, but with a hundred more steps).

    Leave a comment:


  • aviallon
    replied
    Originally posted by rene View Post
    the usual modern "just change for the sake of change" it has been there for decades, and software uses it in production. No reason to change to make some students hello world FP math work like in the textbook. If this lands upstream I'll just revert it for our t2 package for high performance optimizations ,-) https://t2sde.org/packages/llvm
    You just have to replace -Ofast with -O3 -ffast-math, and you're done.

    Leave a comment:


  • ms178
    replied
    Originally posted by jabl View Post

    If the developer of the code in question doesn't endorse using -Ofast / -ffast-math (e.g. by having that option in the build configuration of the software in question), and you don't have the competence to analyze whether it's safe, then, well uh-oh, don't go and enable it?
    Sure, that is another simple solution and I understand the reasoning behind it. The problem is that I don't want to leave any performance on the table and a large number of users are in the same boat that don't know about the details of the code base nor do users know if the devs care about Ofast or performance at all. My current practice is to follow what Clear Linux does or test it out experimentally on a package-by-package basis. I think this could be improved further, my dream would be to have an AI optimizing the source code to the machine where the code is executed, creating optimal code for the specific target.

    Leave a comment:


  • User42
    replied
    There's something missing in the article. I refuse to believe that totally optional but convenient flag would be removed on the ground that "people don't read the doc" (my paraphrasing).

    I'm all for providing better UX but such a flag was introduced by GCC to get close to the convenience of the Intel Compiler -xfast to compile high-performance computing workload (and I guess a lot of AI stuff these days). They are not equivalent but it gets a long way there for numerical workloads that don't heavily depend on IEEE compliance.

    Removing it because incompetent morons, who choose their flags by hear instead of reading the doc, use it when they shouldn't merely displaces the problem while being inconvenient for all current users.

    Leave a comment:

Working...
X