C＃/ XNA - 乘法比分区更快？

Question

I saw a tweet recently that confused me (this was posted by an XNA coder, in the context of writing an XNA game):

Microoptimization tip of the day: when possible, use multiplication instead of division in high frequency areas. It's a few cycles faster.

I was quite surprised, because I always thought compilers where pretty smart (for example, using bit-shifting), and recently read a post by Shawn Hargreaves saying much the same thing . I wondered how much truth there was in this, since there are lots of calculations in my game.

I inquired, hoping for a sample, however the original poster was unable to give one. He did, however, say this:

Not necessarily when it's something like "center = width / 2". And I've already determined "yes, it's worth it". :)

So, I'm curious...

Can anyone give an example of some code where you can change a division to a multiplication and get a performance gain, where the C# compiler wasn't able to do the same thing itself.

Answer 1

Most compilers can do a reasonable job of optimizing when you give them a chance. For example, if you're dividing by a constant , chances are pretty good that the compiler can/will optimize that so it's done about as quickly as anything you can reasonably substitute for it.

When, however, you have two values that aren't known ahead of time, and you need to divide one by the other to get the answer, if there was much way for the compiler to do much with it, it would -- and for that matter, if there was much room for the compiler to optimize it much, the CPU would do it so the compiler didn't have to.

Edit: Your best bet for something like that (that's reasonably realistic) would probably be something like:

double scale_factor = get_input();

for (i=0; i<values.size(); i++)
    values[i] /= scale_factor;

This is relatively easy to convert to something like:

scale_factor = 1.0 / scale_factor;

for (i=0; i<values.size(); i++)
    values[i] *= scale_factor;

I can't really guarantee much one way or the other about a particular compiler doing that. It's basically a combination of strength reduction and loop hoisting. There are certainly optimizers that know how to do both, but what I've seen of the C# compiler suggests that it may not (but I never tested anything exactly like this, and the testing I did was a few versions back...)

Answer 2

Although the compiler can optimize out divisions and multiplications by powers of 2, other numbers can be difficult or impossible to optimize. Try optimizing a division by 17 and you'll see why. This is of course assuming the compiler doesn't know that you are dividing by 17 ahead of time (it is a run-time variable, not a constant).

Answer 3

Bit late but never mind.

The answer to your question is yes.

Have a look at my article here, http://www.codeproject.com/KB/cs/UniqueStringList2.aspx , which uses information based on the article mentioned in the first comment to your question.

I have a QuickDivideInfo struct which stores the magic number and the shift for a given divisor thus allowing division and modulo to be calculated using faster multiplication. I pre-computed (and tested!) QuickDivideInfos for a list of Golden Prime Numbers. For x64 at least, the .Divide method on QuickDivideInfo is inlined and is 3x quicker than using the divide operator (on an i5); it works for all numerators except int.MinValue and cannot overflow since the multiplication is stored in 64 bits before shifting. (I've not tried on x86 but if it doesn't inline for some reasons then the neatness of the Divide method would be lost and you would have to manually inline it).

So the above will work in all scenarios (except int.MinValue) if you can precalculate. If you trust the code that generates the magic number/shift, then you can deal with any divisor at runtime.

Other well-known small divisors with a very limited range of numerators could be written inline and may well be faster if they don't need an intermediate long.

Division by multiple of two: I would expect the compiler to deal with this (as in your width / 2) example since it is constant. If it doesn't then changing it to width >> 1 should be fine

Answer 4

To give some numbers, on this pdf

http://cs.smith.edu/dftwiki/index.php/CSC231_Pentium_Instructions_and_Flags

of the Pentium we get some numbers, and they aren't good:

• IMUL 10 or 11
• FMUL 3+1
• IDIV 46 (32 bits operand)
• FDIV 39

We are speaking of BIG differences

Answer 5

 while(start<=end)
    {
    int mid=(start+end)/2;
    if(mid*mid==A)
    return mid;
    if(mid*mid<A)
    {
    start=mid+1;
    ans=mid;
    }

If i am doing this way the outcome is the TIME LIMIT EXCEEDED for square root of 2147483647

But if i am doing the following way then the thing is clear that for Division compiler responds faster than for multiplication.

while(start<=end)
    {
    int mid=(start+end)/2;
    if(mid==A/mid)
    return mid;
    if(mid<A/mid)
    {
    start=mid+1;
    ans=mid;
    }
    else
    end=mid-1;
    }