which one is faster/better > or >=

[Mahdi]

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i 0) {// do stuff}
2- if(i >=1) {// do stuff}

Thanks.

--
Mahdi.

[Alun Harford]

Mahdi wrote:

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i 0) {// do stuff}
2- if(i >=1) {// do stuff}

They both get jitted to the same x86 code on my machine.

public static void Main(string[] args)
{
for (int i = 0; i < 10; i++)
{
if (i 0) i++;
if (i >= 1) i++;
}
}

The code in the middle becomes:

if (i 0) i++;
0000001a test esi,esi
0000001c jle 0000001F
0000001e inc esi
if (i >= 1) i++;
0000001f test esi,esi
00000021 jle 00000024
00000023 inc esi

Alun Harford

[Marra]

They execute in the same time.

[Rudy Velthuis]

Mahdi wrote:

Hi

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i 0) {// do stuff}
2- if(i >=1) {// do stuff}

There should absolutely be no difference.

--
Rudy Velthuis http://rvelthuis.de

"Quotation confesses inferiority." -- Ralph Waldo Emerson

[Larry Smith]

Of course. But in some cases you need all the speed you can get and have

to sacrifice some readability. I know the situations would be rare but
they still exist where every bit of speed is required.

"Rare" is an understatement. I'd challenge anyone to show me a real-world
Windows program where slicing and dicing a few nanoseconds is going to make
any appreciable difference even if you could pull it off. The ambient
temperature of the room probably has a greater impact on performance.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Mahdi wrote:

This seems like a crazy question but I wanted to find out if anyone
knows which one of those two conditions are better (faster, smaller
memory footprint, can be optimized by the compiler, etc..)

1- if(i 0) {// do stuff}
2- if(i >=1) {// do stuff}

I agree with the others that have suggested to spend your time
on something more productive.

I will just add one additional note: you can measure current
..NET version on current CPU's. But there are not guarantee that
the results will stay valid forever.

Arne

[Michael C]

"Larry Smith" <no_spam@_nospam.comwrote in message
news:ef**************@TK2MSFTNGP03.phx.gbl...

"Rare" is an understatement. I'd challenge anyone to show me a real-world
Windows program where slicing and dicing a few nanoseconds is going to
make any appreciable difference even if you could pull it off. The ambient
temperature of the room probably has a greater impact on performance.

It's not that rare. Any algorithm that loads all its data at the start, does
some lengthy processing, and saves the results at the end will benefit. I
have four such algorithms in my app.

Michael

[Larry Smith]

>"Rare" is an understatement. I'd challenge anyone to show me a real-world

>Windows program where slicing and dicing a few nanoseconds is going to
make any appreciable difference even if you could pull it off. The
ambient temperature of the room probably has a greater impact on
performance.

It's not that rare. Any algorithm that loads all its data at the start,
does some lengthy processing, and saves the results at the end will
benefit. I have four such algorithms in my app.

This type of hairsplitting won't benefit you in any way you'll ever notice.
From a performance perspective, it's a complete waste of time even thinking
about it.

[Michael C]

"NvrBst" <nv****@gmail.comwrote in message
news:cd**********************************@h11g2000 prf.googlegroups.com...

Basically I have a question very simular to the first; is doing this
type of thing (== to < && >) faster for C# (C# is what I mainly use
now)? Or just an urban myth of the past? Its always been something
in the back of my mind that I've been curious about but never got
around to actually testing myself.

My guess is it would be slower by a small amount but you never know. Maybe
on some processor a < is faster than =. The only way to know is try it.

Michael

[Michael C]

"Larry Smith" <no_spam@_nospam.comwrote in message
news:Ok**************@TK2MSFTNGP02.phx.gbl...

This type of hairsplitting won't benefit you in any way you'll ever
notice. From a performance perspective, it's a complete waste of time even
thinking about it.

One thing I wanted to add was that if creating a fast algorithm then
something like this would just be one tool in the toolchest. It might gain a
1% advantage but in combination with other optimisations it could give real
benefits.

Michael

[Ian Semmel]

"Michael C" <mi**@nospam.comwrote in message
news:OV**************@TK2MSFTNGP03.phx.gbl:

"Larry Smith" <no_spam@_nospam.comwrote in message
news:Ok**************@TK2MSFTNGP02.phx.gbl...

This type of hairsplitting won't benefit you in any way you'll ever
notice. From a performance perspective, it's a complete waste of time

even

thinking about it.

One thing I wanted to add was that if creating a fast algorithm then
something like this would just be one tool in the toolchest. It might
gain a
1% advantage but in combination with other optimisations it could give
real
benefits.

Michael

1% ??? It must be the most trivial algorithm of all time.
or
You meant .00001%

[Michael C]

"Ian Semmel" <an****@rocketcomp.com.auwrote in message
news:OC**************@TK2MSFTNGP03.phx.gbl...

1% ??? It must be the most trivial algorithm of all time.
or
You meant .00001%

Not necessarily. It just needs to be in a loop that doesn't have a lot of
code in that particular loop. There could be loops within loops within
loops. The inner most loop might be very trivial but that does not mean the
algorithm is. The other thing is the loop might well be extremely trivial,
such as flipping some bits in a bitmap.

Michael