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

131–140 of 198 posts

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

#131

Post by BeeOnRope »

xxs wrote: post #19

Writing (compiler) microbenchmarks is notoriously hard. Overall no benchmark should run fewer than two mins or so to account for context switching noises at least. It should run on fixed CPU frequency (no turbo boost, etc), fixed CPU core(s) too. It should be aware of L1/L2 cache sizes - data crossing L1/L2 boundaries on different processors results in disproportional results. The difference in compilers is too high…

Two minutes!?

You can write good microbenchmarks that run in as little as a few nanoseconds.

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

#132

Post by BeeOnRope »

noselasd wrote: post #11

So on my machine it's 0.72 ns/int (+/- 2.5 %) vs 0.90 ns/int (+/- 2.5 %) for normal cases when no overflow/traps actually occurs. When an overflow/trap occurs, a possible severe bug, it's 0.74 ns/int (+/- 2.5 %) vs 9.12 ns/int (+/- 2.1 %)

How did you measure the speed of the trapping scenario, since the program terminates in that case?

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

#133

Post by BeeOnRope »

kazinator wrote: post #48
olliej wrote: post #24

The problem with integer overflow, in the general context of UB, isn't that it's expensive to trap. The problem is that the C (and C++) specs insist on overflow being undefined behavior. Then compilers insist on abusing the UB as meaning that they get to do whatever they want. This particular case is only partially the compiler's fault, as the various specs should not be defining well specified behavior as being unde…

C compilers should assume that every bit of code is necessary. The only dead code is that which is predicated on a compile-time constant, as in: if (0) { /* safe to ptimize this away */ } Code which tests a run-time condition must always be assumed to be doing that for a reason. Just provide excellent code generation: great peephole optimizations, jump threading, instruction selection: all the "classics". Try to put…

The number of people who want the language and compiler implementation you are describing is vanishingly small.

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

#134

Post by andi999 »

account42 wrote: post #124
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…

> Anyway usually anything below 10ms is random. I don't think you realize how much time 10ms is for a computer. Games need to render an entire frame in under 7 ms to hit my monitor's max refresh rate.

I know that 10ms is long and a lot of things can happen. Like adobe thinks it needs an update and the windows scheduler thinks your task needs a pause (thats the worst case) other things can happen as well. Anyway usually i found low time benchmarks not reliable, if you found them reliable thats good.

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

#135

Post by jjnoakes »

scoutt wrote: post #126
MaxBarraclough wrote: post #55

Earlier quoted context omitted.

> 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.

I guess people overreact to "undefined behavior". If your software runs always on the same platform then you can know what the behavior would be. It might also be intentional and should not crash your program. Undefined behavior is used when doing a specification for a compiler that will be used in many architectures and they cannot clearly specify what would happen on ALL architectures for a given operation, because…

> If your software runs always on the same platform then you can know what the behavior would be.

This is not necessarily true, and I consider it to be a harmful misconception.

I think people under-react to "undefined behavior".

What you think the platform would do if you overflowed an integer using machine instructions and what your C or C++ code ends up executing can be wildly different things because C and C++ compilers do everything in their power to optimize your code assuming your signed integers will never overflow. If they do, who knows what state your program is in or which machine instructions the compiler would have scheduled.

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

#136

Post by asveikau »

lmm wrote: post #62
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. 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? If you don't abort then you probably have an arbitrary code execution vulnerability. Overflow is undefined behaviour in C++, your code is in an unanticip…

> If you don't abort then you probably have an arbitrary code execution vulnerability.

There are some patterns in which that is totally true, for example if an integer product is passed to malloc or realloc. Those cases tend to get extra scrutiny in security reviews because it is a well known class of issues. However, it is certainly not the case that every case is exploitable.

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

#137

Post by Dylan16807 »

_hl_ wrote: post #61
titzer wrote: post #56

Earlier quoted context omitted.

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…

Right, but afaik only one instruction per 'hyperthread' is fetched every cycle, but I'm happy to be corrected here.

https://en.wikichip.org/w/images/7/7e/skylake_block_diagram.... Way more than that.

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

#138

Post by asveikau »

gpderetta wrote: post #54
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.

And that's one reason that when I write code that divides and it's not known ahead of time, I usually check the denominator for zero.

Doing that for every mathematical operation would not be feasible.

Edit: hello good sir or madam downvoter, can someone explain why this is a controversial opinion? In languages where this error does not throw exceptions and in problem domains where the process really needs to stay up, reasonable caution would often mean you might manually check possible denominators for zero.

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

#139

Post by saeta »

zeotroph wrote: post #84
masklinn wrote: post #78

Earlier quoted context omitted.

> Is it just about signed numbers or not? No. You can plug an `UInt8(255)` in an online playground and try to increment it, it’ll crash unless you use an overflowing operator. > Also, what other languages are there that are "like Swift"? In debug mode, Rust will panic on overflow (regardless of signing). You can also enable overflow-checks in release mode.

So is Swift effectively adding a jo / jump on overflow instruction after each normal integer operation?

`+` is checked for overflow by default (can be overridden with compiler flags), and `&+` is overflowing addition and does auto-vectorize equivalently to C++.

I'd be quite interested in seeing a benchmark comparing checked and unchecked addition that doesn't get auto-vectorized to understand the performance in practice for non-numerical computing.

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

#140

Post by scoutt »

jjnoakes wrote: post #135
scoutt wrote: post #126

Earlier quoted context omitted.

I guess people overreact to "undefined behavior". If your software runs always on the same platform then you can know what the behavior would be. It might also be intentional and should not crash your program. Undefined behavior is used when doing a specification for a compiler that will be used in many architectures and they cannot clearly specify what would happen on ALL architectures for a given operation, because…

> If your software runs always on the same platform then you can know what the behavior would be. This is not necessarily true, and I consider it to be a harmful misconception. I think people under-react to "undefined behavior". What you think the platform would do if you overflowed an integer using machine instructions and what your C or C++ code ends up executing can be wildly different things because C and C++ com…

You are right. I might correct the sentence with "you can often know". Undefined behavior should be avoided but really is not that terrible.
Post reply on HN