[rust-dev] Integer overflow, round -2147483648

Gregory Maxwell gmaxwell at gmail.com
Mon Jun 23 14:11:08 PDT 2014


On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay <danielmicay at gmail.com> wrote:
> I already mentioned the issue of undefined overflow, and how using
> inbounds pointer arithmetic is both higher-level (iterators) and just as
> fast. It doesn't cover every case, but it covers enough of them that the
> use case for undefined signed overflow is reasonable small.

Yes, I think I'm adequately convinced that failure to undefined
overflow is not performance doom, there are other ways to get the same
performance... though they may result in different idiomatic high
performance code than people are writing today. Some code style
evolution is unavoidable I guess.

> Undefined behavior on overflow is also a memory safety issue, while
> wrapping on overflow is not. You can claim that it could cause memory
> safety issues via incorrect unsafe code, but low-level code is going to
> be using wrapping or undefined semantics for performance regardless of
> the default.

It depends on what exactly what is allowed to be done with the undefinedness.

> Slower performance than Java by default would kill off nearly all
> interest in Rust, and would make the claim that it's a viable C
> replacement even less true than it already is.

Calling things 'slower than java' is a little bit hyperbole with the
actual numbers posted here. But I agree any non-trivial slowdown by
default would adversely impact adoption, I don't consider that
desirable.

> I don't understand what the problem would be with my proposal to have
> either `checked { }` or checked operators + a lint for unchecked usage.

My /own/ desire there doesn't even want either of those things, though
I agree they could also be useful.

With the performance concerns aside, my reason for commenting was
wanting the programmers intention to be well specified enough in
widely deployed software that strong static and debug-build dynamic
checking are able to suss out all aspects of software correctness, not
just memory safety.

I think it will be unfortunate if rust takes a step back from C by
resulting in an ecosystem where common idiomatic rust code is less
amenability to tools that help software authors find incorrect code by
reasoning from or trapping on overflow behavior.

>> John was kind enough to post numbers for each of many microbenchmarks
>> instead of a range. Beyond the signed vs signed+unsigned do you have
>> any additional idea why his numbers would be lower than yours?
>
> If you read my response, you'll see that I mentioned the impact of the
> architecture on the results. I also mentioned that the code bloat issue
> does not impact microbenchmarks as they fit entirely into the L1 cache
> with or without the overflow checks. If we're going to play the game of
> picking and choosing benchmarks, I can demonstrate cases where the
> overhead is 1000-2000%.

I'd somehow missed the code bloat point. Sorry about that.


More information about the Rust-dev mailing list