++x is more optimised than x++ ???

[karthikbalaguru]

I came across a nice example and info that claim that ++x is optimised
than x++.
Is it so ?

For example.
for(x = 0; x < 10; x++)
There is a simple fix for this, and it will optimize your loop, ever
so slightly.
for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for those using for
loops like this, this is a much faster way to parse through your
data.

Is it so ? How is it possible that ++x is faster than x++ ?

Thx in advans,
Karthik Balaguru

[jacob navia]

karthikbalaguru wrote:

I came across a nice example and info that claim that ++x is optimised
than x++.
Is it so ?

For example.
for(x = 0; x < 10; x++)
There is a simple fix for this, and it will optimize your loop, ever
so slightly.
for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for those using for
loops like this, this is a much faster way to parse through your
data.

Is it so ? How is it possible that ++x is faster than x++ ?

Thx in advans,
Karthik Balaguru

In theory, ++c just increments c. c++ increments c and returns
the OLD value, so the old value must be saved.

In practice there isn't any difference for most compilers. If
the old value is discarded, they throw the saving of the
old value away and generate the same code as for ++c.

[Tim Prince]

jacob navia wrote:

karthikbalaguru wrote:

>I came across a nice example and info that claim that ++x is optimised
than x++.
Is it so ?

For example.
for(x = 0; x < 10; x++)
There is a simple fix for this, and it will optimize your loop, ever
so slightly.
for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for those using for
loops like this, this is a much faster way to parse through your
data.

Is it so ? How is it possible that ++x is faster than x++ ?

Thx in advans,
Karthik Balaguru

In theory, ++c just increments c. c++ increments c and returns
the OLD value, so the old value must be saved.

In practice there isn't any difference for most compilers. If
the old value is discarded, they throw the saving of the
old value away and generate the same code as for ++c.

It would require a different example, to show an advantage for ++x on
CPUs which support it better in the instruction set, like old PPC Macs.

[Stephen Sprunk]

"karthikbalaguru" <ka***************@gmail.comwrote in message
news:11**********************@d55g2000hsg.googlegr oups.com...

I came across a nice example and info that claim that ++x is
optimised than x++. Is it so ?

For example.
for(x = 0; x < 10; x++)
There is a simple fix for this, and it will optimize your loop, ever
so slightly.
for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for those using for
loops like this, this is a much faster way to parse through your
data.

Is it so ? How is it possible that ++x is faster than x++ ?

Decades ago, when compilers were pretty bad at optimizing, that was likely
true. Nowadays, they should compile to identical instructions except in
cases where the resulting value of the expression matters. For instance, "y
= ++x;" is likely to still be faster than "y = x++;", but the two statements
don't do the same thing.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Kelsey Bjarnason]

On Tue, 04 Sep 2007 17:42:04 +0000, karthikbalaguru wrote:

I came across a nice example and info that claim that ++x is optimised
than x++.
Is it so ?

For example.
for(x = 0; x < 10; x++)
There is a simple fix for this, and it will optimize your loop, ever
so slightly.
for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for those using for
loops like this, this is a much faster way to parse through your
data.

Is it so ? How is it possible that ++x is faster than x++ ?

The reasoning probably goes something like this:

var = ++x stores the incremented value of x in var
var = x++ stores the unincremented value of x in var
some compilers may generate a temporary for this:
temp = x
x++
var = temp
thus you should use ++x instead of x++

The main problem with this is that any compiler worth its salt won't
bother unless the unincremented value is actually needed; in the loop,
it's not. The value of x++ isn't used at all, no need to store the value,
so why bother with the overhead?

A quick test with gcc shows it generating identical code in both cases;
I'd expect the same from pretty much any compiler these days.

[Marjancek]

On Sep 4, 7:42 pm, karthikbalaguru <[e-mail]>
wrote:

I came across a nice example and info that claim that ++x is optimised
than x++.
Is it so ?

For example.
for(x = 0; x < 10; x++)
There is a simple fix for this, and it will optimize your loop, ever
so slightly.
for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for those using for
loops like this, this is a much faster way to parse through your
data.

Is it so ? How is it possible that ++x is faster than x++ ?

Thx in advans,
Karthik Balaguru

Perhaps your post would have more sense in lang.c++, as there there IS
a diference, regardless of the compiler, due to operator overloadings.

Mariano

[Gordon Burditt]

>I came across a nice example and info that claim that ++x is optimised

>than x++.

If the value of the expression is not used, the generated code for
++x may be more the same as the code for x++ than the generated
code for x++ is the same as the code for ++x. (Note: Standard C
does not define the "is more equal" operator.) Reasonable compilers
will generate identical code in this case. Identical code is *NOT*
guaranteed to execute at identical speed (consider pipelining, and
cache contents of previous code, task switches, interrupts, etc).

>Is it so ?

Any statement of the form "A is faster than B, A is slower than B,
or A is about the same speed as B" is false (even if B is "Repeat
A one million times"), unless the conditions of test such as CPU,
compiler version AND checksum, and compile-time options are specified.

>For example.
for(x = 0; x < 10; x++)
There is a simple fix for this, and it will optimize your loop, ever
so slightly.

There is no guarantee of that. Reasonable compilers will generate
identical code in both cases.

>for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for those using for
loops like this, this is a much faster way to parse through your
data.

Or it could COST kiloseconds.

>Is it so ? How is it possible that ++x is faster than x++ ?

Standard C does not guarantee anything about performance.

[Jack Klein]

On Tue, 04 Sep 2007 17:42:04 -0000, karthikbalaguru
<ka***************@gmail.comwrote in comp.lang.c:

I came across a nice example and info that claim that ++x is optimised
than x++.

Whose nice example? Why do you think it is reliable? The net is full
of junk. When it comes to programming, more bad than good.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Peter Nilsson]

Tim Prince <[e-mail]:

jacob navia wrote:

karthikbalaguru wrote:

I came across a nice example and info that claim that
++x is optimised than x++.
Is it so ?

Note that the answer in C++ is different because x may be
a class with overloaded increment operators.

For example.
for(x = 0; x < 10; x++)
There is a simple fix for this,

It's not a _fix_, it's a micro-optimisation.

and it will optimize your loop, ever so slightly.

It may make it faster, it may make it slower. But if the
change will only save 20 seconds cpu time over the 10 years
the program may typically be employed, then it's not even
worth spending 2 minutes profiling!

for(x = 0; x < 10; ++x)
It can save milliseconds on your code rotations, for
those using for loops like this, this is a much
faster way to parse through your data.
>
Is it so ? How is it possible that ++x is faster than x++?

In theory, ++c just increments c. c++ increments c and returns
the OLD value, so the old value must be saved.

In practice there isn't any difference for most compilers. If
the old value is discarded, they throw the saving of the
old value away and generate the same code as for ++c.

It would require a different example, to show an advantage for
++x on CPUs which support it better in the instruction set,
like old PPC Macs.

The difference is usually much clearer with pointer increments...

while (*s++ = *t++) /* mac 68k */
;

verses

if (*s = *t) /* pentium & ppc */
while (*++s = *++t)
;

You will find cases where compiler optimisation isn't perfect
at things like...

while (i-- < 10)
...stuff...

....but it's usually a compiler issue, not an instruction set
issue.

--
Peter

[Ark Khasin]

Peter Nilsson wrote:

The difference is usually much clearer with pointer increments...

while (*s++ = *t++) /* mac 68k */
;

verses

if (*s = *t) /* pentium & ppc */
while (*++s = *++t)
;

You will find cases where compiler optimisation isn't perfect
at things like...

while (i-- < 10)
...stuff...

...but it's usually a compiler issue, not an instruction set
issue.

--
Peter

It often /is/ an instruction set issue.
If memory serves me right, e.g. in ARM in Thumb mode pointers are
optimized for post-increment and pre-decrement.
It's a different story that a good compiler would virtually rewrite your
snippet of code in an equivalent and faster-for-this-machine way.
To do so, it needs to recognize your snippet as transformable: it's the
best reason to write the code in cliches (common idioms) and avoid
clever constructs and blocks nested CHAR_BIT deep :)
-- Ark

[Martin Wells]

Kathik:

Is it so ? How is it possible that ++x is faster than x++ ?

As regards C++, either could be more efficient depending upon the
user's definition of the overloaded operator function. And, in
general, the user's prefix version tends to be faster than the postfix
version because the postfix version tends to involve creating a copy.

But we're talking about C here.

The purpose of x++ is to take the value, then increment it. (Quite
easily understood when reading from left to right).

The purpose of ++x is to increment it, then take the value. (Quite
easily understood when reading from left to right).

Now ask yourself, why should opening a door and then closing a window
be any faster than closing a window and then opening a door? (No smart-
allec answers thank you very much, such as that it depends whether
you're downstairs and the window is upstairs).

In the following code:

Func(x++);

, why should there be any kind of copy? Why wouldn't it simply be
treated as "take the value, then increment"? i.e.:

Func(x); ++x;

Anyway, to answer your question, if any compiler even makes a
difference between the two expressions (assuming the value of the
expression is discarded), then I'd probably get myself a different
compiler.

Martin

[pete]

Martin Wells wrote:

>
Kathik:

Is it so ? How is it possible that ++x is faster than x++ ?

As regards C++, either could be more efficient depending upon the
user's definition of the overloaded operator function. And, in
general, the user's prefix version tends to be faster than the postfix
version because the postfix version tends to involve creating a copy.

But we're talking about C here.

The purpose of x++ is to take the value, then increment it. (Quite
easily understood when reading from left to right).

The purpose of ++x is to increment it, then take the value. (Quite
easily understood when reading from left to right).

Now ask yourself, why should opening a door and then closing a window
be any faster than closing a window and then opening a door?
(No smart-allec answers thank you very much,
such as that it depends whether
you're downstairs and the window is upstairs).

In the following code:

Func(x++);

, why should there be any kind of copy? Why wouldn't it simply be
treated as "take the value, then increment"? i.e.:

Func(x); ++x;

That doesn't mean the same thing.
There's a sequence point between argument evaluation
and the actual function call.

(++x, Func(x - 1)) means the same thing as Func(x++).

/* BEGIN new.c output */

10
00
10

/* END new.c output */
/* BEGIN new.c */

#include <stdio.h>

void Func(int y);

int x;

int main(void)
{
puts("/* BEGIN new.c output */\n");

x = 0;
Func(x++);

x = 0;
Func(x); ++x;

x = 0;
(++x, Func(x - 1));

puts("\n/* END new.c output */");
return 0;
}

void Func(int y)
{
printf("%d%d\n", x, y);
}

/* END new.c */
--
pete

[Martin Wells]

pete:

Func(x); ++x;

That doesn't mean the same thing.
There's a sequence point between argument evaluation
and the actual function call.

I over-simplified the example for sake of the discussion.

Martin

[Richard]

Martin Wells <wa****@eircom.netwrites:

pete:

Func(x); ++x;

That doesn't mean the same thing.
There's a sequence point between argument evaluation
and the actual function call.

I over-simplified the example for sake of the discussion.

Martin

This is not, as you have discovered, the place to do that. Although in
this case I think it was worth highlighting the difference as it would
be very instructive for a newbie learning C and convincingly
demonstrates sequencing in a simple, straightforward manner.

[Army1987]

On Wed, 05 Sep 2007 17:13:25 -0700, Martin Wells wrote:

In the following code:

Func(x++);

, why should there be any kind of copy? Why wouldn't it simply be
treated as "take the value, then increment"? i.e.:

Func(x); ++x;

What if Func somehow knows x's address? There is a sequence point
after the arguments are evaluated and before the function is
called, so it should see the incremented value.

Maybe ++x, Func(x - 1); would do it.
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[pete]

Richard wrote:

>
Martin Wells <wa****@eircom.netwrites:

pete:

Func(x); ++x;

That doesn't mean the same thing.
There's a sequence point between argument evaluation
and the actual function call.

I over-simplified the example for sake of the discussion.

Martin

This is not, as you have discovered, the place to do that. Although in
this case I think it was worth highlighting the difference as it would
be very instructive for a newbie learning C and convincingly
demonstrates sequencing in a simple, straightforward manner.

And I want to restate that
(++x, Func(x - 1)) means the same thing as Func(x++)
and also say:
that the two expressions mean the same thing
regardless of the return type of Func and
regardless of whether or not x is an expression of type int
with an initial value of INT_MAX.

--
pete