@mjk I'm disappointed to see that rust just lets you go hog wild with floating point non-determinism like a filthy C programmer. They should have banished floating point arithmetic to the "unsafe" zone.
@aeva@mjk Also, I don't think Rust has floating point non-determinism. We have non-deterministic NaN generation because we support platforms that don't support deterministic NaNs. https://github.com/rust-lang/rfcs/pull/3514
@saethlin@mjk wait wait wait you're telling me that rust just leaves NaN as platform-specific undefined behavior?!! Does this mean rust is vulnerable to NaN poisoning and INF poisoning bugs?
@aeva@saethlin@mjk Not "real deal" undefined behavior - float arithmetic is safe and can therefore never yield UB - but platform-specific behavior indeed.
@aeva@saethlin@mjk In this case, not the entire behavior is left to the vendor - it's bounded. Real UB can mean anything, including memory corruption, arbitrary code execution, 10.0 CVE etc. In the float case the behavior is still constrained to produce a valid value of the type and no other adverse effects.
@muvlon@saethlin@mjk sure, floating point math probably isn't going to let russians hack into joe biden's computer or whatever, but it can give people seizures and crash airplanes if you're not relentlessly disciplined about how you handle it.
@mjk ok so I was being a little glib with the fp non-determinism thing because society is not ready for a language that enforces equivalent fp ops to always happen in the same order, but I do get real actual wild crazy eyes about NaN and INF poisoning bugs because I've fixed enough of them that were causing surprise strobing that could trigger seizures that I really do believe being blase about this is the kind of negligence that can hurt or kill people.
@mjk this is something that could realistically be prevented with static analysis without sacrificing that sweet sweet perf we all love, and afaik nobody has bothered to do so.
@aeva@mjk If you don't want nans you can make them fault! genuinely a pretty good approach for gameplay code where you're not expecting to generate them. (btw with regards to ordering, rust is deterministic, so it should produce the same values on all compilers (caveat, maths libraries), just not necessarily the same NaNs)
@dotstdy@mjk "with regards to ordering, rust is deterministic" wait, are you saying that rust is able to ensure that fp mul and add ops are commutative?
@aeva@dotstdy@mjk wait am I missing something? fp mul and add are commutative, what they are not is associative and distributive. And they are deterministic for implementations that are IEEE-754-compliant.
@oblomov I probably mixed part of it up. What I am used to people meaning by "floating point non-determinism" is the fact that you will get a different rounding error depending on the order in which you performed a fp calculation. This can very quickly compound into systemic non-deterministic behavior, which is where the name comes from. This is a big problem in games and CAD software, and probably a lot of other applications.
@aeva yeah, that's non-associativity, i.e. (a op b) op c != a op (b op c). Maybe it's just my pedantry, but non-determinism conveys (to me) the idea that the same ops in the same order may give different results (which isn't the case).
(And yes, it does require extra care, but ultimately it's the price one pays for a higher dynamic range. Fixed-point is “more associative” (not perfect either, TBH), but has its own issues.)
@aeva@mjk Err, not sure what you mean there. If you write some maths in rust it will generate the same values on all platforms. However if you flip around the order you calculate things, then it won't produce the same values because that's fundamental to floating point.
@aeva@mjk In C++ the only things that aren't "deterministic" in floating point are like, execution order of function args, different stdlib implementations of math functions, and if you use the scary "fast-math" break my code switch. So it's not a huge difference between them.
Sadly, even without fast-math the default value of the FP_CONTRACT pragma may be ON (standard states the default value is implementation-defined), and that by itself does enough damage. So rustc effectively works like C++ with FP_CONTRACT OFF?
Add comment