4 ms·

If you'd follow the steps of the code you wrote, you'd see that when the same values travel the same code paths they end up being always exactly the same. Unle

by scott_s 14y ago

If you'd follow the steps of the code you wrote, you'd see that when the same values travel the same code paths they end up being always exactly the same. Unless, of course, the "code paths" you're talking about are at the C level. In that case, it is possible for optimizations (or lack of it) to end up with slightly different values for the same C code. How often things are moved in and out of the FPU registers can impact things (as I point out elsewhere), as well as if the C compiler orders operations differently.

acqq 14y ago
Once one code path is optimized it is what it is, there can be nothing "slightly different" as long as your code is the same, if you get different results for the same inputs you don't follow the same path. When you change the code, you have the brand new landscape -- it's you who changed it. Moving out of the FPU registers will happen in always the same points before you change the code, and even where moving out occurs you won't observe 80 bits partial results unless you intentionally turn that feature on. If you have any specific counterexample I happily welcome it.
- scott_s 14y ago
  Once one code path is optimized it is what it is, there can be nothing "slightly different" as long as your code is the same You have missed my point. For the author, he thinks of "the code" as the C code that he can see. The fact that passing different compiler flags may result in "the code" ending up in different machine code is not something he's used to thinking about. So you have to be careful when explaining such concepts to beginners.
  - acqq 14y ago
    I disagree. Changing FP optimizations is not something that can surprise anybody in producing different results. If the results were exactly the same we wouldn't need different options in the compiler as there wouldn't be a trade off to decide about. It's the "religious" claims (presenting very well thought-through engineering as if some god, magic or a random number generator is inside, it's not) that motivate some people to say things like "we'll never know." You won't if you approach it dogmatically or fatalisticaly.
    - monochromatic 14y ago
      You don't think it could possibly surprise anyone that changing optimization level can change the meaning of the program?
      - acqq 14y ago
        When you turn on FP optimizations you say to the compiler "sacrifice some bits here and there, give me more speed." I don't know any manual that explains such options and doesn't make that clear. Counterexamples welcome here too.
        monochromatic 14y ago
        I'm not saying you're wrong about what it does, or even about whether it's documented. I'm saying that most compiler optimizations don't behave that way, and I can certainly see this being a surprise to someone who views optimizations generally as correctness-preserving transformations.
        scott_s 14y ago
        Because people may not realize that such things are possible, they may not realize that, say, -ffast-math in gcc is dangerous. Yes, the man page says it right there, but that assumes you know what that means.

by scott_s 14y ago

acqq 14y ago

Once one code path is optimized it is what it is, there can be nothing "slightly different" as long as your code is the same, if you get different results for the same inputs you don't follow the same path. When you change the code, you have the brand new landscape -- it's you who changed it. Moving out of the FPU registers will happen in always the same points before you change the code, and even where moving out occurs you won't observe 80 bits partial results unless you intentionally turn that feature on. If you have any specific counterexample I happily welcome it.

scott_s 14y ago
Once one code path is optimized it is what it is, there can be nothing "slightly different" as long as your code is the same You have missed my point. For the author, he thinks of "the code" as the C code that he can see. The fact that passing different compiler flags may result in "the code" ending up in different machine code is not something he's used to thinking about. So you have to be careful when explaining such concepts to beginners.
- acqq 14y ago
  I disagree. Changing FP optimizations is not something that can surprise anybody in producing different results. If the results were exactly the same we wouldn't need different options in the compiler as there wouldn't be a trade off to decide about. It's the "religious" claims (presenting very well thought-through engineering as if some god, magic or a random number generator is inside, it's not) that motivate some people to say things like "we'll never know." You won't if you approach it dogmatically or fatalisticaly.
  - monochromatic 14y ago
    You don't think it could possibly surprise anyone that changing optimization level can change the meaning of the program?
    - acqq 14y ago
      When you turn on FP optimizations you say to the compiler "sacrifice some bits here and there, give me more speed." I don't know any manual that explains such options and doesn't make that clear. Counterexamples welcome here too.
      - monochromatic 14y ago
        I'm not saying you're wrong about what it does, or even about whether it's documented. I'm saying that most compiler optimizations don't behave that way, and I can certainly see this being a surprise to someone who views optimizations generally as correctness-preserving transformations.
      - scott_s 14y ago
        Because people may not realize that such things are possible, they may not realize that, say, -ffast-math in gcc is dangerous. Yes, the man page says it right there, but that assumes you know what that means.