On Tuesday 23 April 2013 08:02:22 Patrick Walton wrote: > On 4/23/13 7:48 AM, [email protected] wrote: > > Performance should be about the same when using F-division: > > * Performance will go up for division by constant powers of two. > > * Performance will stay the same for division by compile-time constants, > > since these are transformed by the compiler into multiplies. (I > > actually think performance will go up slightly in this case, but it's > > been a while since I looked at the algorithm.) * Performance on ARM > > will stay the same for divides by variables (not known at > > compile-time), since ARM does not have a hardware divider. * > > Performance on x86/x64 for divides by variables will go down slightly, > > since Intel's idiv instruction implements F-division.> > > So one already very slow operation (x86 idiv) gets slightly slower, one > > fast operation (divide by power-of-two) gets quite a bit faster. It > > probably nets out near zero. > I worry quite a bit about that last one. Rust language semantics strive > to mirror the CPU instructions as closely as possible. This is why, for > example, we were forced to make `<` respect NaN, unlike Haskell--if we > didn't, we couldn't use the hardware floating point comparison instructions. > > I'm also nervous about C interoperability. > > Including F-division as a library function sounds fine to me > though--macros or dot notation may be able to sweeten the syntax.
May I jump on the band-wagon? I also worry slightly about C interop — not from using libraries but because copy and paste subtly changes the meaning. However, I agree with Erik — F-division should be the default. For any case in which I've cared, it's what I've wanted, and I've had a couple of bugs because it's not in C++ (in code like arr[(ind - offset) % size]). I suspect (please correct me if I'm wrong) that if it wasn't for C and x86 compatibility then most people would fall into two categories: don't know/don't care, and prefer F-division. It's one of those little things like tau vs. pi which would have been less confusing if we'd started off on the other foot to start with. Diggory _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
