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.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
