Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How expensive is integer-overflow trapping in C++?

lemire.me

Post reply on HN
Print view View original

51–60 of 198 posts

Re: How expensive is integer-overflow trapping in C++?

#51

Post by chrisseaton »

raverbashing wrote: post #50
rightbyte wrote: post #44

Earlier quoted context omitted.

Usually you don't really care that much about the overflow cost if it is an error right?

True but do you care for all sums/muls in your code? Might be better to check where exactly can you have the overflows and test in the code for those cases. I think checking for overflows over the entire code is useful for testing/validation purposes but not really useful in production. Or use bigger data types if you're hitting overflows frequently.

> Might be better to check where exactly can you have the overflows and test in the code for those cases.

Compilers already track possible ranges and do this.

Re: How expensive is integer-overflow trapping in C++?

#52

Post by pjmlp »

kzrdude wrote: post #27
bleepblorp wrote: post #15

It's worth mentioning that x86 CPUs had a single instruction overflow test that would raise a hardware interrupt in response to an integer overflow. This allowed for extremely low cost integer overflow tests. Unfortunately, this capability was deleted from x86-64 and we're now stuck with either accepting the risks of integer overflows or suffering a performance hit to test for them by using multiple instructions. Ano…

This was interesting, intel mpx is seen as a failure https://en.m.wikipedia.org/wiki/Intel_MPX

While Solaris on SPARC ADI is doing just fine, and there are ongoing efforts on ARM.

Intel just missed the mark once more.

Re: How expensive is integer-overflow trapping in C++?

#53

Post by gpderetta »

praptak wrote: post #31
wmil wrote: post #26

Earlier quoted context omitted.

There's an integer overflow flag that gets set after operations. My x86 books are all boxed up somewhere so I can't look up the details.

As I understand this is about trapping, which makes overflow checking free for non-overflowing operations. Flag checking, as opposed to trapping, incurs costs on all operations.

INTO would still need to check the flags and you would need to invoke it after every operation that could overflow. You can't configure the integer ALU to raise an interrupt automatically after any overflow.

Re: How expensive is integer-overflow trapping in C++?

#54

Post by gpderetta »

asveikau wrote: post #8

Aborting the program on integer overflow seems so drastic. Say you do that in a server program. Then convincing it to overflow an integer somewhere (possibly somewhere where it is harmless) causes denial of service and all unrelated connections in the process die? I guess languages with support for exceptions have a more natural action for this, that could be caught somewhere in a server's processing loop to not affe…

FWIW, division by zero already does the same thing.

Re: How expensive is integer-overflow trapping in C++?

#55

Post by MaxBarraclough »

asveikau wrote: post #8

Aborting the program on integer overflow seems so drastic. Say you do that in a server program. Then convincing it to overflow an integer somewhere (possibly somewhere where it is harmless) causes denial of service and all unrelated connections in the process die? I guess languages with support for exceptions have a more natural action for this, that could be caught somewhere in a server's processing loop to not affe…

> Aborting the program on integer overflow seems so drastic.

Disagree. Overflowing of a signed integer type is undefined behaviour, which deserves to be taken seriously.

I was surprised to see that the article doesn't mention the signed/unsigned distinction, or undefined behaviour. Overflowing of a unsigned integer type is not a problem, it's defined to wrap around, and may be done intentionally.

Re: How expensive is integer-overflow trapping in C++?

#56

Post by titzer »

_hl_ wrote: post #14
andi999 wrote: post #12

I read the sourcecode and it seems the array is 1000 elements (with random elements). If each sum supposedly need 0,1ns then the whole process is around 100ns=0,1 ms. I do not think you can do benchmark on these timescales. Then the algo is repeated on the same data 40 times and averaged. This also doesnt help too much. So the first run puts everything in L1 cache and then it runs much faster. Anyway usually anything…

> each sum supposedly need 0,1ns Sub-cycle latency for an addition would be quite amazing... Nevertheless your point remains. > 100ns=0,1 ms 0.1μs, not 0.1ms

Modern superscalar processors have more than one execution unit. The latest Intel microarchitecture has 10 execution ports, which means it can theoretically execute 10 μ-ops per cycle. With a 200+ entry reorder buffer, the processor is trying hard to cram those execution units full every cycle. How successful it is depends on dynamic data dependencies and fetch/issue bandwidth. At 3ghz, to reach 0.1ns latency (on average), it only needs to achieve 3 instructions per clock.

Re: How expensive is integer-overflow trapping in C++?

#58

Post by formerly_proven »

saagarjha wrote: post #43
formerly_proven wrote: post #32

Earlier quoted context omitted.

Integer overflow should have been implementation-defined behavior from day one, because that's what it actually is.

Implementation defined means that the behavior is defined. This is patently not what the existing behavior of compilers in the face of integer overflow is.

I'm trying to say that integer overflow is architecture-specific, so it _should_ have been standardized as implementation defined.

Re: How expensive is integer-overflow trapping in C++?

#59

Post by quietbritishjim »

> adding two large integers can result in an integer that cannot be represented in the integer type. We often refer to such error conditions as overflows.

There's a subtlety here that's missed in the article: In C and C++ this is only called "overflow" for signed integers. That's because that word specifically refers to the case where the behaviour is undefined, and for unsigned integers the result is always well defined: it is the correct result modulo the size of the integer type (which must be a power of 2). For example, UINT_MAX + 1 is guaranteed to equal 0. In particular, the -ftrapv flag mentioned in the article is described in the GCC docs as (emphasis mine):

> This option generates traps for signed overflow on addition, subtraction, multiplication operations.

(Another subtlety, albeit a bit less likely to cause confusion: with signed integers it's possible that the result is negative but doesn't fit into the type, e.g. INT_MIN-1, and this is also called overflow. I mention it because it's tempting to call this "underflow", but that word is reserved for talking about floating point numbers where the result is too small in magnitude to be represented by a non-zero value.)

I don't know Swift at all so I'm quite curious about this bit of the article:

> In a programming languages like Swift, an overflow will result in the program aborting its execution.

Unfortunately, because the article is sloppy about the meaning of "overflow", I don't know how to interpret it. Is it just about signed numbers or not? Also, what other languages are there that are "like Swift"?

Re: How expensive is integer-overflow trapping in C++?

#60

Post by andi999 »

titzer wrote: post #56
_hl_ wrote: post #14

Earlier quoted context omitted.

> each sum supposedly need 0,1ns Sub-cycle latency for an addition would be quite amazing... Nevertheless your point remains. > 100ns=0,1 ms 0.1μs, not 0.1ms

Modern superscalar processors have more than one execution unit. The latest Intel microarchitecture has 10 execution ports, which means it can theoretically execute 10 μ-ops per cycle. With a 200+ entry reorder buffer, the processor is trying hard to cram those execution units full every cycle. How successful it is depends on dynamic data dependencies and fetch/issue bandwidth. At 3ghz, to reach 0.1ns latency (on ave…

I fully agree with your post. I am just not sure if you are trying to make a point for larger datasets in benchmark (like I did) or you are trying to imply that this is not necessary?
Post reply on HN