28 ms·
> and that code that needs to produce the exact same result ... is broken. "The same result" is a complicated question when floating point computations are inv
by greglindahl 7y ago
> and that code that needs to produce the exact same result
... is broken. "The same result" is a complicated question when floating point computations are involved. Even in an IEEE 754 environment, the compiler can easily cause non-bit-exact differences over time on the same chip.
- creato 7y agoI agree that code that depends on exact results from things that are known to depend on implementation defined behavior is broken code. But the reality is that a ton of scientific and high performance code does it, and simply declaring it broken and not dealing with it will not do you any favors if you are trying to work with such systems. It's similar to how microsoft has to maintain decades of bugs because a ton of software depends on them and would break if they fixed them. Yeah, microsoft would be "correct" to fix them and declare the code buggy. But that would piss off a lot of people that don't care about this argument and probably lose microsoft money. It's the same situation here.
- greglindahl 7y agoI deal with it by using the numerical skills I used in grad school. There are no surprises here for anyone who's studied scientific computing. You appear to not understand the issues involved. Robust code doesn't have a problem with different compilers or implementation-defined behavior that's within bounds.
- creato 7y agoGood for you? I didn't originally write most of the code I have to work with. Just like intel doesn't write the code that depends on MKL.