Click here to Skip to main content
15,881,812 members
Please Sign up or sign in to vote.
1.00/5 (3 votes)
See more:
I am confused as this question was asked to me in an interview.
I think addition is faster but dont know the reason.
Posted
Updated 15-Oct-14 20:40pm
v2

Now you are not at the interview. Time it or use the CPU reference; such references always provide information of bus cycles taken by each command. (Such questions should be asked about some particular CPU; however, it's hard to imagine that there can be any difference).

Strictly speaking, the question is incorrect. The instruction-set architectures typically (not all of them) have different timing for different commands like that. How can they be different? Different types (floating-point calculation can be done in a different part of CPU, called FPU) makes big difference, but also sources and targets of the operations can make considerable difference (memory, register).

—SA
 
Share this answer
 
I guess, this question was just asked to confuse you. For one, it is not the C or C++ language that dictates the time for an addition or subtraction, but the processor. For two, most of today's processors are implemented in a way that addition and subtraction are basically done with the same resources. If there is any difference in execution time, it is subordinate. So your your answer should have been: For all practical purposes they run with the same speed. But note: The same is NOT true for multiplication and division. Usually division is a lot slower.
 
Share this answer
 
Comments
Tarun_Pant 21-Oct-14 2:15am    
But i think that subtraction is also a binary addition done by doing 2's compliment which is a 2 step process...this is the reason what i gave to him in support to my answer....but dont know it is right or wrong
nv3 21-Oct-14 5:03am    
That thought is in principle correct, except that building the 2's complement is so fast that it doesn't add to the processing time. Take a look at instruction latency tables like this one: http://www.agner.org/optimize/instruction_tables.pdf. ADD and SUB or FADD and FSUB have the same latency time and are in fact listed in the same entry. So at least for current AMD and Intel 32- and 64-bit architectures it is safe to say that addition and subtraction take the same time. What is much more of influence to execution time is whether operands have to be loaded from memory or can be fetched from the cache, or are present in registers.
The other solutions are correct, it's mainly up to the implementation of the processor.

I decided to try it. Below is a test for N = 10000000, addition took .035s and subtraction took .044s.

Edit: this editor converts > to &gt and & to &

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

void add(int *a, int b)
{
    *a = *a + b;
}

void sub(int *a, int b)
{
    *a = *a - b;
}

void runAddTest(int n)
{
    int i=0;
    while(n-->0)
    {
        add(&i,1);
    //printf("%d, ",i);
    }
    //printf("\n");
}

void runSubTest(int n)
{
    int i=n;
    while(n-->;0)
    {
        sub(&i,1);
        //printf("%d, ",i);
    }
    //printf("\n");
}

int main()
{
    int N = 10000000;
    printf("Running, please wait...\n");

    clock_t t;
    t=clock();
    runAddTest(N);
    t=clock() -t;

    clock_t t2=clock();
    runSubTest(N);
    t2=clock() -t2;

    printf("Addition: Time %f seconds.\n",((float)t)/CLOCKS_PER_SEC);
    printf("Subtraction: Time %f seconds.\n",((float)t2)/CLOCKS_PER_SEC);

    getchar();
    return 0;
}
 
Share this answer
 
v2
Comments
[no name] 17-Oct-14 0:35am    
This example has problems. You are using a low resolution timer to measure a relatively small elapsed time - suggest QueryPerformanceCounter(). Your timing should be done inside the function call - you don't want to measure how long a function call takes. I wouldn't call another function to do the adding and subtracting - that adds further timing unknowns. You should then average many runs because you don't know what else the cpu is up to. This example uses integers but the OP was not specific and as SA has stated floating point is another matter.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900