Explicit type conversion vs using type rules

Question

Suppose that I have this program :

#include <iostream>

using namespace std;
int main() {
    unsigned int n, i;
    double sum = 0;
    cout << "\n No. of terms: ";
    cin >> n;
    for( i=1; i<=n; i++ ) {
        sum += i/(i+1.0);       //// THE LINE IN QUESTION
    }
    cout << " Sum = " << sum;
    return 0;
}

It calculates sum of series : 1/2 + 2/3 + 3/4 .. to n/n+1.

Now i want to ask that in the for loop where i wanted to assign int value to double variable sum, i can do that by two ways :

1. method 1: sum += i/(i+1.0)
2. method 2: sum += (double) i/(i+1)

Which is faster or better way?

Ligth races in orbits : What i mean is that which method should be used.

Answer 1

As a rule of thumb, such minor differences aren't likely to matter. There is a difference of one or two cycles out of the roughly 20 or so cycles (most taken by the division) this is going to take, if there is one at all.

These are the operations your two methods perform:

Method 1

a   = (double)i; // convert to double
b   = 1.0;       // load double
c   = a + b;     // double addition
sum = a / c;     // double division

Notice that we only have to do one conversion to double as the compiler can do an optimization called common subexpression elimination. On many machines (like x86) you cannot simply add a floating point constant to a number, you have to load the constant into a floating point register first so I count that as an extra instruction. If you are doing this in a loop, the 1.0 needs to be loaded only once though.

Method 2

a   = (double)i; // convert to double
b   = i + 1;     // int addition
c   = (double)b; // convert to double
sum = a / c;     // double division

Here we need to do two conversions but we can save a floating point load and we can replace a floating point addition with a cheaper integer addition.

Machine code

Here is amd64 assembly for both methods:

method1:
        pxor     %xmm0, %xmm0      // clear result register
        movsd    .one(%rip), %xmm1 // load 1.0
        cvtsi2sd %edi, %xmm0       // convert int to double
        addsd    %xmm0, %xmm1      // double addition
        divsd    %xmm1, %xmm0      // double division

.one:
        .double 1.0

method2:
        pxor     %xmm0, %xmm0      // clear result register
        pxor     %xmm1, %xmm1      // clear register for i + 1
        cvtsi2sd %edi, %xmm0       // convert int to double
        addl     $1, %edi          // increment
        cvtsi2sd %edi, %xmm1       // convert int to double
        divsd    %xmm1, %xmm0      // double division

Both methods seem to be pretty equal in terms of operations. I recommend you to benchmark this if you want to be sure.

Answer 2

Method one results in two conversions from integer to double, one double addition, and one double division.

Method two results in a conversion from integer to double, an integer addition, converting the integer result to double, and one double division.

It's fairly likely that the compiler will optimize two identical conversions of integer to double in method 1. I don't believe that a compiler will ever optimize the first method down to the second one, due to integer overflow-related issues, so I'll just assume a reasonably intelligent compiler that can execute the obvious optimization.

So we have:

1. Convert integer to double
2. Double addition
3. Double division

Versus:

1. Convert integer to double
2. Integer addition
3. Convert integer to double
4. Double division

So the difference between the two methods reduces to a double addition operation versus integer addition and conversion of integer to double.

Regarding "which one is faster": the difference is not directly comparable, so this will depend entirely on whichever CPU is going to execute this. I don't know of any empirical evidence that all CPUs will handle one or the other set of operations always faster than the other one.

Regarding "which one is better": the better approach is the one that you think is more readable, and maintainable. That's because whichever approach turns out to be faster in practice, the "faster" part will so insignificant, on modern CPUs, that it can be practically ignored, and the remaining factor to consider is simply readability and maintainability; and insofar which one of the two approaches is more readable or maintainable, this is going to be purely a matter of one's taste.

Unless, of course, one has to implement something like this in certain very narrow, tailored, situations where every nanosecond matters, and a huge pile of money depends entirely on the proposition that "faster=better". In which case the only way to obtain the answer is to rigorously benchmark the execution profiles of both methods on your target hardware platform, and figure out by yourself which one is "better".