Hacker News Reader

Comment by sounds | Hacker News Reader

Modern CPUs don't like traps ("exceptions"). The exception causes a pipeline flush which kills performance for math-intensive code.

For example, detecting integer overflow on x86 and x86_64 CPUs is easy: check the overflow flag after every arithmetic operation. It would only be slightly more difficult to detect overflow for SSE (vector) operations, which would require doing some bit masking and shifting.

For a language such as Swift, building it in is simple.

View on HN

The entire premise of the linked article is that doing it the way you suggest is too expensive for the common case, where no overflow happens. Further, it implicitly asserts that the cost of a hardware trap/exception, while great, will be offset by the savings from the common case.

Now, it doesn't back these assertions with much data, but neither do you :)

Exactly -- the premise would be that non-overflowing arithmetic would be the "fast path" and overflow would be truly exceptional.

This is similar to null-reference protection in various languages and runtimes, where null dereferences are caught by mapping guard pages at the beginning of memory. Dereferencing a pointer is optimistic and assumes that it will succeed, the same as arithmetic operations would in this proposal.

The problem with a hardware implementation is that you break algorithms and coding systems for which integer overflow, or rather integer wrapping, is a necessary piece rather than an exception case. You could, in theory, add an instruction that disables integer exceptions, but that would make the hardware more complicated. You could also redesign the aforementioned algorithms and systems to not rely on the implicit wrapping, but then you make them more expensive.

No one is advocating eliminating modulo arithmetic - the trapping instructions would be different ops, just like on architectures that already implement this such as MIPS.

OK, so then its on the compiler to use the non-exception-generating instructions when generating the assembly.

The problem is that potentially-overflowing integer instructions make a real mess out of things like out-of-order execution and speculative execution.

For data to back this, see your favorite computer architecture reference, particularly anything that discusses the consequences of highly-complex instructions in things like the VAX.

Citing stuff from the 80s RISC movement is pretty outdated nowadays, especially in this specific case where quintessential RISC architectures such as MIPS implemented trapping arithmetic instructions from the start.

To the contrary, out-of-order execution and speculative execution make precise exceptions trivial to support. As long as exceptions are not frequent, there is no performance pentalty either. It's the older in-order pipelines who struggle with precise exceptions. But there are well-known tricks to work around that too...

I suspect the best solution would be something like NaN behaviour: carry on with your performance-critical arithmetic and then examine the final result for validity.

Exceptions are - by definition - rare, and when they happen you have other problems than worrying about performance or pipeline flushes.

It means that your program contains a bug.

What's swift got to do with it anyway? A language that was launched last week is now a benchmark for including new features? Has it been open sourced since then? If not how is building it in simple?

Reply on news.ycombinator.com