On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson <bander...@mozilla.com> wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson <dbau...@gmail.com> wrote: >>> >>> On 11/01/14 16:58, Isaac Dupree wrote: >>>> >>>> Scheme's numeric tower is one of the best in extant languages. Take a >>>> look at it. Of course, its dynamic typing is poorly suited for Rust. >>>> >>>> Arbitrary-precision arithmetic can get you mathematically perfect >>>> integers >>>> and rational numbers, but not real numbers. There are an uncountably >>>> infinite number of real numbers and sophisticated computer algebra >>>> systems >>>> are devoted the problem (or estimates are used, or you become unable to >>>> compare two real numbers for equality). The MPFR C library implements >>>> arbitrarily high precision floating point, but that still has all the >>>> pitfalls of floating-point that you complain about. For starters, try >>>> representing sqrt(2) and testing its equality with e^(0.5 ln 2). >>>> >>>> In general, Rust is a systems language, so fixed-size integral types are >>>> important to have. They are better-behaved than in C and C++ in that >>>> signed >>>> types are modulo, not undefined behaviour, on overflow. It could be >>>> nice to >>>> have integral types that are task-failure on overflow as an option too. >>> >>> >>> We do already have some Checked* traits (using the LLVM intrinsics >>> internally), which let you have task failure as one possibility on >>> overflow. >>> e.g. http://static.rust-lang.org/doc/master/std/num/trait.CheckedAdd.html >>> (and Mul, Sub, Div too). >> >> I don't think failure on overflow is very useful. It's still a bug if >> you overflow when you don't intend it. If we did have a fast big >> integer type, it would make sense to wrap it with an enum heading down >> a separate branch for small and large integers, and branching on the >> overflow flag to expand to a big integer. I think this is how Python's >> integers are implemented. > > > I do think it's useful and is potentially a good compromise for the > performance of the default integer type. Overflow with failure is a bug that > tells you there's a bug. Wrapping is a bug that pretends it's not a bug. > > Hitting a slow path unexpectedly on overflow seems to me like a recipe for > unpredictable performance, which doesn't seem inline with Rust's usual > goals.
The branch on the overflow flag results in a very significant loss in performance. For example, I had to carefully write the vector `push` method for my `Vec<T>` type to only perform one overflow check. With two checks, it's over 5 times slower due to failed branch predictions. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
