Hacker News new | ask | show | jobs
by chrismorgan 1994 days ago
I quibble with your characterisation of IEEE 754 ubiquity being mindlessly cargo-culted, because there’s a runtime cost to doing things any other way. Specifically, all mainstream hardware has instructions that work the IEEE 754 way, so if you want to not propagate NaN, I believe you’ll need to either implement those operations manually, or check for NaN after every operation and convert it into an exception or panic or whatever. I’m not certain what the cost would be, being no compiler engineer or hand-coder of assembly, but I’m fairly confident that there is one. I suspect that cost may also be inordinate on various realistic workloads.

(Since you mention billion-dollar mistakes: you can remove null pointers from a language at no runtime cost, in a few different ways—e.g. require that types be explicitly nullable, or Rust-style Option<T> optimised to squeeze the None/Some discriminant into any spare space in T, so that for sized T, &T and Option<&T> both take only one word.)
3 comments
lmm 1993 days ago
The issue isn't actually IEEE 754 but rather common C implementations; most hardware supports much more in the way of signalling NaNs and floating point exceptions, but most languages blindly follow the way C does it. It's the same with rounding modes; 754 provides a decent range of rounding modes marred by a poor default, but C and everything that follows it expects that default to be used.
link
swiftcoder 1993 days ago
> I’m not certain what the cost would be, being no compiler engineer or hand-coder of assembly, but I’m fairly confident that there is one. I suspect that cost may also be inordinate on various realistic workloads.

Back in the PowerPC days, something along these lines happened with Java. Java mandates that integer divide-by-zero throws an exception, but PowerPC doesn't have a mechanism to signal that a divide-by-zero occurred (1/0 == 0, as far as PowerPC is concerned). This forced the JVM to wrap every integer divide with an explicit test for a zero divisor, which put a significant drag on JVM performance...

link
marcosdumay 1993 days ago
People have been pushing for overflow checks for integer arithmetic on C on the basis that the cost isn't too high. For floating point it can only be lower.

We are probably talking about single-digit percent increases in run time. For some software that's relevant, but not for most.

link