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

21–30 of 198 posts

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

#21

Post by Gibbon1 »

jojobas wrote: post #3

From GCC documentation, >The compiler will attempt to use hardware instructions to implement these built-in functions where possible, like conditional jump on overflow after addition, conditional jump on carry etc. I suspect something's not exactly right with compiler flags. Then again, how much of your program is integer arithmetic? 12x slowdown on 0.1% is 1.2%.

What I find annoying is we go back and forth over this because the insistence on clinging to the one true holy int type as on Gods Blessed Machine the PDP 11. Instead of implementing proper variable types like you have with Ada.

Seriously considering code can compiled for on 16, 32, and 64 bit machines 'int' is dodgy as hell.

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

#22

Post by alblue »

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…

This is essentially Swift’s problem on the server. If you have a service running and serving hundreds of clients, then any one of those threads can cause a trivial panic if there’s an overflow and take the entire service down.

As a result, a number of use cases for swift on the server actually use heavyweight out of process threads (i.e. one process per client) so that the failure of one of them doesn’t take down the rest.

Unfortunately there’s no way of overriding the panic (is implemented as an in-line ud2 instruction rather than an overridable function) and while you can install a signal handler to catch it, resuming isn’t straightforward and there are some cases where you really can’t do anything about it (malloc failure).

This works great for single user devices where there’s only one app running at once and when it crashes the user restarts it, but doesn’t work in the server case unless you are using a cgi-bin/lambda pattern when each request is processed by a new process each time, which is what TF and the AWS lambda approaches do.

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

#23

Post by sanxiyn »

lytigas wrote: post #6
fluffy87 wrote: post #2

Note that Rust also traps on integer overflow, and it is trivial to „hack“ the compiler to disable this, and many have done so. While on this microbenchmark you see a 3x slowdown with the LLVM backend, on large Rust projects like servo, Firefox, the rust compiler, etc. the slowdown is not even measurable. Also, Rust provides you with unsafe intrinsics to opt-out of trapping in the particular line of code in which it…

Rust wraps in release mode and traps in debug mode[0][1]. All large projects that I know of ship in release mode. Though I'd be interested to see a source for it not pessimizing badly. [0] https://play.rust-lang.org/?version=stable&mode=release&edit... [1] https://github.com/rust-lang/rfcs/pull/560

It is quite believable that trapping does not slow down Firefox. GCC is part of SPECint, and trapping is known not to slow down SPECint GCC. (It does slow down other SPECint benchmarks.)

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

#24

Post by olliej »

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

Fully in the compiler's fault is the treatment of UB meaning "now I can do whatever I want", which turns the compiler into a security adversary. I have yet to see a non-microbenchmark, non-spec benchmark, that demonstrates a real world win by subverting the developer's intent.

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

#25

Post by ckwalsh »

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…

In prod it's not a great idea, but in a test environment, perhaps handling simulated or shadow traffic, it's great.

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

#26

Post by wmil »

chrisseaton wrote: post #18
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…

I wasn’t aware of this - which instruction do you mean?

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.

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

#27

Post by kzrdude »

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

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

#28

Post by gopalv »

chrisseaton wrote: post #18
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…

I wasn’t aware of this - which instruction do you mean?

I think the GP was probably thinking of INTO(0xCE).

https://en.wikipedia.org/wiki/INT_(x86_instruction)#INTO

The bounds-checking was MPX, I think.

> Another extremely useful instruction deleted from x86-64 tested if an array access was in bounds.

https://en.wikipedia.org/wiki/Intel_MPX#Extensions

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

#29

Post by gsg »

wmil wrote: post #26
chrisseaton wrote: post #18

Earlier quoted context omitted.

I wasn’t aware of this - which instruction do you mean?

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.

That still exists though? add rax, rbx/jo overflow_error is how you do overflow checking on x86-64.

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

#30

Post by nly »

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…

Even measuring using something like Google Benchmark this is very tricky to measure.

https://quick-bench.com/q/Qv0fbR1ThuL5-uqbfYI62qhy5vY

YMMV

Post reply on HN