On Wed, Apr 24, 2013 at 5:43 AM, Graydon Hoare <[email protected]> wrote:
> How much of a performance penalty is it worth? I believe you can trap this > in C presently with a gcc flag too (-ftrapv); but it's a flag rarely turned > on. > That's a hard question to answer, but if it cost only 1%, I'd say it's a no-brainer. If it cost 10%, I might say it's not worth it. So the question is how much would it cost? I believe the answer will depend on whether the language also does array bounds checking, since there must be a significant amount of synergy between array bounds checking and overflow checking when you try to intelligently optimize them both. For that and other reasons I think it would be difficult to extrapolate from C to Rust (except maybe to establish an upper bound). (I generally concur and wanted rust integers to overflow to bignums > originally! I do NOT want overflow to bignums. I don't think that's useful in a browser and would cause a larger performance penalty than necessary for the no-overflow common case. I think integer overflow should simply cause the task to fail. Overflowing to bignums sounds way more expensive then just failing --- it would introduce internal polymorphism all over the place, and would tightly constrain the scheduling of overflow checks. If overflow simply causes the task to fail, then you (or your out-of-order CPU) can schedule overflow checking very freely. I don't think bignums are useful in a browser because as a browser developer I will choose data types that cover the ranges of values I want to handle. If I think I need to handle integer values that don't fit in 32 bits, I'll use a 64-bit integer type, or a floating point type. Overflow always means I have a bug*. Overflows in the field usually mean my code is being maliciously attacked, in which case fail-fast is definitely the best thing to do. * Sometimes developers use overflow to get modulo-2^N behavior (which is incorrect in C anyway), and intrinsic functions for those operations would be helpful. But I have had to retreat from such stances due to complaints about > performance / not-C-ness. I suspect the attribute mechanism is the right > approach for such pragmas; would it be acceptable to put one attribute in > each of your crates?) > Much better than nothing, but if the overhead of overflow checking is very low, I think the case for making it the default would be very strong. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
