Which one of these would be faster?

[Mythios]

Not sure if there is any speed difference at all. I'm not looking for a correct way of doing it. Just curious which is faster or if they are the same.

if(sInvader.y > 41)
{
    gameRunning = false;
}

or

gameRunning = sInvader.y < 41 ? true : false;

Cheers,
Myth.

[Bazzy]

I think the fastest way would be
gameRunning = sInvader.y < 41;
as there is no need for a condition checking
but it could depend on the optimization

EDIT:
I've tried that.
On VC++ the if way resulted the fastest
On MingW everithing is the same

[Mythios]

Cheers - I'm using VC++ So i'll stick with the if :)

[helios]

I found that, when comparing a variable to a constant, without optimization the if method is faster by two instructions or just as fast; with optimization was harder to measure because the optimizer was rather aggressive and kept merging the if with the call to cout.operator<<. The optimized direct assignment (variable=(variable<constant)) only took two instructions, but wasn't merged with the call, so it might take more.

When comparing a variable to another variable, everything took more or less the same time, both optimized and unoptimized.

Personally, I prefer direct assignment because it makes clearer what the code is doing, besides making it terser, and a few clocks is a small sacrifice.

[rossman231]

I have to agree with helios here. None of the options presented will really ever have a significant effect on the execution time of your program. Algorithms tend to be the things that slow programs down, not semantic choices. Go with whatever is most readable to you.

[Mythios]

Awesome - was just curious but that covers it all. Thanks helips and rossman231!

[Zaita]

I found that, when comparing a variable to a constant, without optimization the if method is faster by two instructions or just as fast;

Counting the number of asm instructions generated by the compiler is not a viable method for determining speed. Since Pipeling was introduced and memory and OS have things like "read-ahead' and predictive execution it's really impossible to tell the speed of any piece of code without running it against a timer. Having that 1 extra instruction is like throwing a pebble into the ocean as far as optimisation is concerned anyways. But that extra instruction could be a catalyst for a bigger speed increase.

http://arstechnica.com/old/content/2004/09/pipelining-1.ars

[helios]

Technically, since C++ is supposed to be portable, we shouldn't even be reading disassembly to try to figure out which is faster, because there's no way to know (or rather, we shouldn't know) what kind of code a compiler will produce for a given CPU. Like rossman said, we should rely more on macro optimizations such as better algorithms or data structures than on micro optimizations, which the compiler is better at, anyway.

[Mythios]

Thanks for that Zaita and Helios. Only other question other than that is. Should one be used over the other one or it really won't change anything. Let that be up to your employer :P

Cheers,
Myth.

[jsmith]

Though I think something like this would fall under #0 in C++ Coding Standards (Sutter & Alexandrescu): Don't sweat the small stuff.