[rust-dev] Integer overflow, round -2147483648
danielmicay at gmail.com
Mon Jun 23 11:28:21 PDT 2014
On 22/06/14 12:16 PM, SiegeLord wrote:
> On 06/22/2014 11:32 AM, Benjamin Striegel wrote:
>> This is a mistaken assumption. Systems programming exists on the extreme
>> end of the programming spectrum where edge cases are the norm, not the
>> exception, and where 80/20 does not apply.
> Even in systems programming not every line is going to be critical for
> performance. There is still going to be a distribution of some lines
> just taking more time than others. Additionally, in a single project,
> there's a nontrivial cost in using Rust for the 20% of code that's fast
> and using some other language for the remaining 80%. How are you going
> to transfer Rust's trait abstractions to, e.g., Python?
Rust's design rejects this kind of reasoning about performance not being
relevant to 80% of the code. The language forces you to deal with
ownership and lifetimes throughout the code, even though it's not going
to speed up most inner loops. It's there to improve the performance
characteristics if the language as a whole. If you don't care about
that, a high-level garbage collected language like F# is a better choice.
>> If you don't require absolute speed, why are you using Rust?
> Because it's a nice, general purpose language? Systems programming
> language is a statement about capability, not a statement about the sole
> type of programming the language supports.
Rust supports checked overflow. It has operator overloading and
> C++ can be and is used effectively in applications where speed is of the
> essence and in applications where speed doesn't matter. Is Rust going to
> be purposefully less generally useful than C++? There's always this talk
> of "C++ programmers won't use Rust because of reason X". Which C++
> programmers? In my experience the vast majority of C++ programmers don't
> push C++ to its performance limits. Are they using the wrong language
> for the job? I don't think so as there are many reasons to use C++
> beside its speed potential.
If you're using C++ and you don't care about performance or code size,
then you're using the wrong tool for the job. C++ doesn't have support
for checked overflow anyway, and there's a significant difference
between pushing the language to the performance limit and opting into a
50% performance hit. Checked overflow turns an overflow bug where the
program continues running into the program exiting abnormally, so it's
still a bug either way. We're not talking about a situation where
performance is being lost for the sake of correctness.
> Rust will never become popular if it caters to the tiny percentage of
> C++ users who care about the last few percent of speed while alienating
> everybody else (via language features or statements like yours). The
> better goal is a) enable both styles of programming b) make the
> super-fast style easy enough so that everybody uses it.
The two choices here aren't 'fast' and 'super-fast'. We're not talking
about the "last few percent of speed" here. Using checked overflow will
reduce the performance of most code with non-trivial usage of integer
arithmetic by 30-70%. The only saving grace is that many applications
use floating point arithmetic, and this would still be unchecked. Even
if the program is bounded by memory bandwidth, the stalls from all of
the extra icache churn are going to have an impact.
Supporting checked overflow well without changing the defaults is fine,
but that hasn't been what I've seen proposed here. I think Rust is
already providing a significant improvement over C by making signed
integer overflow defined, and we do pay in terms of some missed
optimizations from that alone. However, our pointer arithmetic was
switched to being inbounds like C, and you can often just use pointers
instead of relying on integer.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Rust-dev