On 22/06/14 05:48 PM, Masklinn wrote: > On 2014-06-22, at 23:31 , Daniel Micay <[email protected]> wrote: >> On 22/06/14 05:09 PM, Rick Richardson wrote: >>> Apologies if this has been suggested, but would it be possible to have a >>> compiler switch that can add runtime checks and abort on >>> overflow/underflow/carry for debugging purposes, but the default >>> behavior is no check? IMO this would be the best of both worlds, >>> because I would assume that one would really only care about checked >>> math during testing and dev. >> >> You would need to build an entirely separate set of standard libraries >> with checked overflow. > > From my understanding, everything would be built with checked overflow > (unless explicitly disabled/bypassed), and the overflow check could be > disabled at compile-time/. > > I don't think that's a good solution, but that's what Swift's `-Ofast` > does, it completely removes a number of checks (including overflow > checking), essentially making the language unsafe but much faster. > > As a side-question, were the performances of ftrapv (in clang) ever > actually tested? There were some discussion on testing the impact > in Firefox, but that ended up with GCC's ftrapv being broken and > not doing anything, and Firefox not working with clang -ftrapv.
It's important to note that `-ftrapv` only adds checks to signed types and doesn't work with GCC. You need to pass both `-fsanitize=signed-integer-overflow` and `-fsanitize=unsigned-integer-overflow` to clang. > I've not seen any numbers since, just lots of assertions that > it's far too slow to be an option. Here's a benchmark of random level generation that made the rounds on /r/rust and #rust already: https://github.com/logicchains/levgen-benchmarks Here is the result with `clang -O3 C.c`: ./a.out 10 &> /dev/null 0.20s user 0.00s system 99% cpu 0.205 total Here is the result with `clang -O3 -fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow`: ./a.out 10 &> /dev/null 0.31s user 0.00s system 98% cpu 0.313 total So in a real world use case consistently partly of integer arithmetic, it's an absolutely acceptable 50% increase in running time. At that point, Rust would be a much slower language than Java by default and no one would use it.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
