Whether it takes longer on a particular hardware implementation is implementation-dependent. Instruction timing on state-of-the-art Intel processors is complicated, to say the least. But, according to the Intel Architecture Optimization Manula, On intel architectures, The pair of integer ALU pipeline stages can each execute xor and addition operations in one clock cycle. They execute at exactly the same speed.

That’s true for Pentium and later processors. It’s possible that smaller and leaner processors do have different execution times for XOR and ADD; but I would think that — given the prevalence of addition operations in computing, that even tiny processors would use the propogation delay time of an addition operation would for the low limit for a single pipleline stage in any modern microprocess, and all or almost all ancient ones as well. (Despite having taken high-school latin, I also think your spam filter is inappropriate).

Code:

#include

using namespace std;

int main()
{
int k = 1000;
for(int i= 0 ; i<10000; i++)
{
k -= k;
cout << i << endl;
k = 1000;

}
}

and

#include

using namespace std;

int main()
{
int k = 1000;
for(int i= 0 ; i<10000; i++)
{
k ^= k;
cout << i << endl;
k = 1000;

}
}

The difference in complexity between the two operations (if any) is insignificant compared to the transistor budget of the CPU designer, and has been for a couple decades.

If you find a difference, it will be to either (1) a measurement error, or (2) something wonky in your favorite language interpreter.

I used to pay a lot of attention to CPU architecture, counting clock cycles per instruction, and writing benchmarks to verify the variants of instruction sequences. As the CPU designers got a bigger transistor budget, they dropped in bigger circuit blocks to perform common operations in a single cycle, or as close as possible.

I was delighted when CPUs got barrel shifters. Ever try to write efficient graphics ops when bit-shift time is linear to the size of the shift? That was a long time back. (And I found a solution.)

When the Intel 486 came out, I lost interest. Most common operations were at that point were very fast.

There is another aspect to this. The unique logic in a CPU is like lines of code in software (and VLSI design became more like software design). Since then CPUs have become very large programs indeed. Large programs almost invariably have bugs. We normally attribute failures to bugs in software, but some are bugs in hardware, and we do not know the proportion.

With current CPUs, massive hardware and overlapped speculative execution has even removed or minimized the cost of subroutine calls and pointer chasing – in many cases. Instruction clock-cycle counting has not been effective for a long time.

I have modified your code so that it loops around more:

http://pastebin.com/mEZBBYKZ


$ g++ -O2 -o code1 code1.cpp
$ g++ -O2 -o code2 code2.cpp
$ time ./code1 9999999
real 0m5.953s
user 0m5.944s
sys 0m0.002s
$ time ./code2 9999999
real 0m5.974s
user 0m5.971s
sys 0m0.002s


Either that, or we have someone (a student?) with an odd sense of humor.

uname -a ouputs:
Linux lappy 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 23 19:43:46 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

And I’m using gcc 4.4.3.

XOr would probably be harder to teach to my kid than sums. This is a measure of complexity on which addition wins.

We have a stalemate…

(As a sidenote, have you thought of updating your spam protection mechanism to ask for XOrs instead of sums? )

For anything like current desktop and server CPUs, they use a ridiculous amount of hardware to accelerate a single instruction stream. Both operations are common and pretty much dead simple, so I’d expect both to be among the very-fastest instructions.

This is likely true of embedded CPUs, like those used in the iPad and cell phones.

Multiplication might show a bigger difference (compared to simpler operations) between high-end and low-end CPUs.

@Stiber

Multiplication might run at the same speed, but you have to use a different test.

However, at the pure hardware level, XOR is faster than addition since there is no carry bit, but other details obscure that and for all practical purposes, they run at the same speed as instructions.