Are ++ and -- operators really more efficient

[Sac]

Hello All,

In many C books I have come across the statement saying ++ and --
operators are more efficient.
However when I look at the assembler code for ++ and +1 both look
same.
Are there any scenarios where in ++ is more efficient?
Or is it just that above statement does not hold good for modern
compilers.

Thanks
Sac

 

[qarnos]

Hello All,

    In many C books I have come across the statement saying ++ and --
operators are more efficient.
    However when I look at the assembler code for ++ and +1 both look
same.
    Are there any scenarios where in ++ is more efficient?
    Or is it just that above statement does not hold good for modern
compilers.

Thanks
Sac

Why would you expect the generated code for x = x + 1 to be different
to that for ++x? They do the same thing.

Perhaps "more efficient" means fewer keystrokes.

++a_long_identifier_name;

is far easier than

a_long_identifier_name = a_long_identifier_name + 1;

 

[Stephen Sprunk]

In many C books I have come across the statement saying ++ and --
operators are more efficient.
However when I look at the assembler code for ++ and +1 both look
same.
Are there any scenarios where in ++ is more efficient?
Or is it just that above statement does not hold good for modern
compilers.

It was frequently true years ago, where compilers didn't do much, if
anything, in terms of optimization. Many CPUs had/have specific
instructions to increment or decrement a variable, which were more
efficient than addition instructions, but ancient compilers would only
use them in ++ or -- expressions.

It is a non-issue today, and you should probably avoid any book (or web
site) that teaches such "tricks". Worry first about making your code
correct and easy to read; save optimization for after you've proven that
your compiler isn't doing a good enough job for your needs (in which
case, you'll usually be better served by a better algorithm than trying
to make a bad one slightly faster).

S

 

[James Kuyper]

Hello All,

In many C books I have come across the statement saying ++ and --
operators are more efficient.
However when I look at the assembler code for ++ and +1 both look
same.
Are there any scenarios where in ++ is more efficient?
Or is it just that above statement does not hold good for modern
compilers.

You shouldn't use x++ as a substitute for x+1; x++ changes the value of
x. If that change in x matters, it's wrong. If the change doesn't
matter, it's still a bad idea because it wastes time. Are you sure they
weren't comparing ++ with +=1?

Most modern compilers can be counted on to generate effectively
identical code for x++ and x+=1. It's still slightly more efficient to
use x++, but only because ++ takes one less character to type than +=1,
or three less characters than " += 1", which is more readable.

A comparably important issue is that if you intend to use the result of
that expression, in some contexts you'll need to put parenthesis around
(x += 1), whereas you wouldn't have to put parenthesis around x++.

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello All,

In many C books I have come across the statement saying ++ and --
operators are more efficient.
However when I look at the assembler code for ++ and +1 both look
same.
Are there any scenarios where in ++ is more efficient?
Or is it just that above statement does not hold good for modern
compilers.

Thanks
Sac

Any optimizing compiler, its optimizations turned on, will treat ++ and
+=1 the same way. If INC is more efficient (eg. if we are not using
SPARC, for instance, in which INC doesn't particularly exist), code
using INC will most probably be generated.

Of course, I would advise not bothering with such things. Your compiler
can take care of such simple optimizations.

I was working on a project in school last term, and one lovely
individual who was working with me was told that ++i was more efficient
than i++ (which is true, because i++ must create a copy of the original
i to return for evaluation). In trying to optimize the code, he simply
replaced all the increment statements in his for loops with ++i where
they were formerly i++, breaking all the code and causing me hours of
wasted time. Optimizing code in this manner is rarely worth the things
like this caused by it.

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJajIGAAoJEKmxP9YxEE4rXqoP/3PrfnPtopEOr0hNDSHDkTPY
yrSEuSGZPGqvE9eqISAaUyZc/bSbnwgJHb5sVe9qcuVPM4LLviHppT5O59RjfFm+
5WXzlhXDoRGKEI9FnlUgGT+cqAxos6S0gLVS5NEaL8xk+zaU3RF9RJzEPIEVp6xI
yWgZv9p/7VoaQWlJQTVoauqgDYH/ZEWc/WrhnS7EnxMp6SFqfyBLJT06FLgdQd/z
6DuMlaZYbU/Es4G+ezj4bJreLPY+vT74p3whn/ddgkCzivExjNwo7bz8e8Fy4MJ6
dpQKwh6JQAxeFfP0OR68O4CzLq0IK04sQQDt3gnJBRDvNXjNfomn3ftkF1lerHLZ
LETsF9v1c3TIC5K0tNj9QlsdTJi4zCh+YSwtZUWbIhH9mUpwqbLvXHJt0LIVnyAu
cLSFiXwriMI7vNZWWNKhUx8fQ6JbfxPtCfS9SEMIBaMBFQ03CUWvb6XLHOXfTUhB
AkU//m0hjMXYg3yDFBmsFbTEZnBjCZM3t2FfAaDtAS98dHA073YW80KwIsikYRXi
sB1TidQzdF9seUkfhbwalcXZYOKvVN3r7SislsW7RyLCxbq0qtRkzsEzIw6VEgng
FP4qRpWR+pgYKtDbSJRXDrVJhy9bQPBJbvV7qOpZ1O3ZCqAf3EgCXCMMBSnfQ1X5
gvJXupW7c+IhGbk66iWk
=aErl
-----END PGP SIGNATURE-----

 

[Richard Tobin]

I was working on a project in school last term, and one lovely
individual who was working with me was told that ++i was more efficient
than i++ (which is true, because i++ must create a copy of the original
i to return for evaluation).

[/QUOTE]

That's true, or more accurately can be true, in C++ overloaded operators. In
C code I can't think of anywhere it would make a difference.

Presumably even in C++ it only makes a difference when the old value
is used, in which case you can't just blindly substitute it.

-- Richard

 

[Richard Tobin]

Any optimizing compiler, its optimizations turned on, will treat ++ and
+=1 the same way.

Even a non-optimising compiler may well do so. The intermediate
representation used for generating code may be exactly the same
in both cases.

-- Richard

 

[Keith Thompson]

That's true, or more accurately can be true, in C++ overloaded operators. In
C code I can't think of anywhere it would make a difference.

Presumably even in C++ it only makes a difference when the old value
is used, in which case you can't just blindly substitute it.[/QUOTE]

<OT>
In C++, either "i++" or "++i" might invoke an overloaded operator,
which means that it calls some function. If the compiler doesn't
know exactly what that function does, its opportunities to rearrange
code are severely limited. Even if "++i" would do exactly the
same thing as "i++", the compiler doesn't know that, so it can't
safely replace a call to the user-written function behind "++i"
with a call to the user-written function behind "i++". On the
other hand, if the overloaded operator is in the standard library,
the compiler might be able to use its knowledge of how the standard
library works to perform some optimization.

On the other hand, the compiler can always tell whether a given
occurrence of "i++" or "++i" invokes an overloaded operator or not,
and if it doesn't, it's free to do the same optimizations that a C
compiler could perform.
</OT>

C, of course, has no overloaded operators (at least standard C
doesn't), so the compiler always knows just what "i++" or "++i"
will do.

 

[Keith Thompson]

Does any architecture have an op zero? This is the operation that is
to zero as addition is to one and multiplication is to two.
a .0. b = a + 1 if a <> b, a + 2 if a == b.

Where "<>" means not equal or "!=". (Some might not be familiar with
the use of "<>" in Pascal or BASIC.)

I don't know of any. How is such an operator useful? And how does
your analogy make any sense?

In C, it could be expressed as

a += 1 + (a==b);

Repeated addition is multiplication, repeated multiplication is
exponentiation, and so forth. I've sometimes thought about a
hypothetical operator such that repeated <whatever> is addition,
but I was never able to come up with anything consistent or useful.
Your "op zero" doesn't qualify either, unless I'm missing something
(which is entirely possible).

 

[Keith Thompson]

Think

a .0. a .0. a

On the first op a == a so we get a + 2, on the second op the left hand
doesn't equal the right, so we obtain a + 3.

Now consider

a + a + a

That equals a * 3, does it not ?

Now

a * a * a

equals a^3 (^ is the exponentiation operator)

The pattern is the same.

Interesting.

Back to my other question: how is this useful?

 

[Charles Richmond]

In the old days we used to have two instructions INC for incrementing a
register, and ADD for adding a constant.

ADD required an extra trip to the data bus to get the value to add, yes
it did. And a compiler would interpret ++ as "INC" and += 1 as "ADD".

On some earlier processors (like the PDP-11 and the MC68000), some
assembly instructions had an "auto-increment" and "auto-decrement"
variation. The instruction would use the value of "i" and then
*also* do the increment or decrement--all in the same instruction.

It *might* make this optimization easier if you used "i++" or such.
(That is, using an "auto-increment" instead of a separate "add"
instruction.) But a good optimizer would spot this anyway. So the
*best* you can say is that "i++" *might* encourage an optimization.

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does any architecture have an op zero? This is the operation that is to
zero as addition is to one and multiplication is to two.
a .0. b = a + 1 if a <> b, a + 2 if a == b.

What exactly does that operator do, in boolean logic terms?

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJamuAAAoJEKmxP9YxEE4r9K0P/Ah7j6Y0bGzb1sMt6I1DCVVK
c74RV4I1DefKQ5SRWeUMgaKK7ljZiwjJuJUk5XtCRQROOP3zqmWFcSf4fqW7hB0K
JnqgZ1W7HdjIvjA0Gbmer6CQvTckgTcC8XMyIwoRnJHQaThNtnORIFM46Gyh+1QF
FzPfFK/VhJKjZuedH065NyvSbMsGUHMuhMmZAfMmOdH7nA9aB8oD2ouSwVuGCaDd
S3QxjZx8ESHGJQm9M9lgjoP7ZQ1bLTPaxbooVJZlseN2PtzQWTqJt8u8tIAiwKfb
TT/Mwt/QEJBVovWbmOIZcmcl33qD9XJxvbdQVCQD07BAx+1TT0XLSTuwfA4Asd7g
elkHg1pLyHdk5MrXFZ90UjIL8Ld1NaqHhAIiozZg3MDp8lpma3lAUbOcSNv9CxUO
1UmlwEYWAWfdYyYxb9dfLYwbcwa9n83yocM3xfya4qaoMMKv4ijPWWTV2eUeq6NZ
ClzuRpSj9s1uJTDRryvu6PXoX/QBEPM9m8kr83XFe+o+78yD9bqPQ4jXoH81AABM
vkVNC4faMfWJmO+vgAXGvivtJmoxFS+M9oQ9WZTq6t82idRZedR0Hpoq7rkq9C8j
qJ1wU3CeXJx2f507OcaM3i5MHCX5v3HrI8PZOYxhkazPuqEqjwNWZuJdMVTq6L0Q
rRXhAmW2L83KLneR71ir
=8Kq+
-----END PGP SIGNATURE-----

 

[Ian Collins]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJamuAAAoJEKmxP9YxEE4r9K0P/Ah7j6Y0bGzb1sMt6I1DCVVK
c74RV4I1DefKQ5SRWeUMgaKK7ljZiwjJuJUk5XtCRQROOP3zqmWFcSf4fqW7hB0K
JnqgZ1W7HdjIvjA0Gbmer6CQvTckgTcC8XMyIwoRnJHQaThNtnORIFM46Gyh+1QF
FzPfFK/VhJKjZuedH065NyvSbMsGUHMuhMmZAfMmOdH7nA9aB8oD2ouSwVuGCaDd
S3QxjZx8ESHGJQm9M9lgjoP7ZQ1bLTPaxbooVJZlseN2PtzQWTqJt8u8tIAiwKfb
TT/Mwt/QEJBVovWbmOIZcmcl33qD9XJxvbdQVCQD07BAx+1TT0XLSTuwfA4Asd7g
elkHg1pLyHdk5MrXFZ90UjIL8Ld1NaqHhAIiozZg3MDp8lpma3lAUbOcSNv9CxUO
1UmlwEYWAWfdYyYxb9dfLYwbcwa9n83yocM3xfya4qaoMMKv4ijPWWTV2eUeq6NZ
ClzuRpSj9s1uJTDRryvu6PXoX/QBEPM9m8kr83XFe+o+78yD9bqPQ4jXoH81AABM
vkVNC4faMfWJmO+vgAXGvivtJmoxFS+M9oQ9WZTq6t82idRZedR0Hpoq7rkq9C8j
qJ1wU3CeXJx2f507OcaM3i5MHCX5v3HrI8PZOYxhkazPuqEqjwNWZuJdMVTq6L0Q
rRXhAmW2L83KLneR71ir
=8Kq+
-----END PGP SIGNATURE-----

Do you have to include all that PGP baggage for a one line question?

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Falcon Kirtaran wrote:

Do you have to include all that PGP baggage for a one line question?

Yes. You are welcome to pay it no attention, or to verify it. I'm not
really a fan of being impersonated. If you knew how many attacks I
sustain on my network in a day, and how much hate mail I get (God only
knows why), you'd probably understand why I care about security. Lots
of newsreaders ignore and/or automatically verify it. Given that it is
less than 1k per message, I can't imagine it is a terrible issue.

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJandcAAoJEKmxP9YxEE4rX4oQAJxzsLvTr25+7IS9WmunJ4MK
ebes35kX9Tq43vP0wtvmoU6aSDyTLDYQbUbaCdlXGHW1hSbWoZeC4PBQJEE2HO9N
6vndIMfHvzrqbD8IDNK16Yy6WN4ruVfCmPN39NuUeD8VLW1cdxa4t8AUkcuM2t93
QVCCbyySUuA0U61aphHjQ1B1udvL+Lbg6NzKsTBWMIGFHSBbUflf7FQkkrLf64um
kBFo3Lo7nxN80vSikDd7mIsjxMc6iTGcBK/h2mosgudSpXzkWNnS1U9lepQjUrQ/
9LbhU4eLviNkjN+0BsxhntDn6zD+vUeTgxlgS5jL9h88VPIpcC8mqkZ3o6b3T4V8
B99+Y+aavBG+Kl0Wjh0YJgE3X+6EJEiLDpM4nVrWYdjTSRs2LzKsW3dLWe6RPisj
NSarmbsph4sUzTwM/Bex8cazp27HS29Mt2mU0UoiJep8WFRs9l1ZvDfZc579Npsp
Hv1kFbiQbMJSVMcnZNmtOtZHoes1mRTJa9dg9ldFDCYIc0u+YW1lajOL7CgwTSEd
w+d6KQqSuqGXA0u+tbrQfPUSxhLUkpgv52X8D5Ln4D+gBzl1LM+datnyy7bPa+RC
rVF7so10SSo71oF7xCnmB+yesG7MK5VzDFM5tB4Yg07lhY1aBG3WkIQGaCEKYJRy
xELyQ75Cihv78D2p402w
=hbR8
-----END PGP SIGNATURE-----

 

[Bart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Yes.  You are welcome to pay it no attention, or to verify it.  I'm not
really a fan of being impersonated.  If you knew how many attacks I
........
xELyQ75Cihv78D2p402w

It was pretty annoying actually. Can't you put this stuff in the
headers?

And how does it stop someone impersonating you? Anyone can add a dozen
lines of gobbledygook at the end of a message. *You* might be able to
tell it's a forgery, but surely you would know that anyway, unless you
have a really bad memory.

Besides, for all *I* know, this is not really you replying.

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It was pretty annoying actually. Can't you put this stuff in the
headers?

And how does it stop someone impersonating you? Anyone can add a dozen
lines of gobbledygook at the end of a message. *You* might be able to
tell it's a forgery, but surely you would know that anyway, unless you
have a really bad memory.

Besides, for all *I* know, this is not really you replying.

I don't think I can put it in headers.

The idea is that if there was a dispute, or any question, literally
anyone who could be bothered to download GPG could easily verify the
signature.

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJaoonAAoJEKmxP9YxEE4r3OQQAMMqZxtS2SZj7cu4H4EXsz9Q
s3TWJvi4QLJ2NSc2/JaZDbR7GYG+Z4hQzHqih1MuYiIVbXzybfXms3s9/102Pu3m
Gbn4YXUrhDS9Nyg8uEylGxWwLfAMaBOL3cDu7TfFE1ayJgggMoUTPXrZn8cLb/iI
jjgdhtBBwlVejgGZiBCNJM/u8KA78wxVSCd9tLvpV6KwfJST66DRFusgL6L9/E05
wW6N44SaRzUAQUqQmfqNlZDkNR1q06EvRtKs2Ec1Glo0rGWFjWHGlLXsaNYcqU68
YFlxihqBCmqUPnBdClutLT6Z+ubb3aXYi/8+1alx+laRMafzgp7pIrxiFOVR07s6
NEa2GEshb1uzZMQ8lz0sy0haSjYwPKYLqjCBWj3SH1vRiN1AyOtuaDoqQHKW3Hlm
zOUc6A2w7T6NKxoiN0113bhdJXb4Ap9L1jNCqFi/2SbLaVRtSgTgT72gNE9wLRhu
ZMn8WjIQomUqI/13WYHT5Gqrzw8IBeWOdjJ6tLHopRc3u5+7ndrqNbQjVpHl/93p
fIoxBANcuaDfBvwYlRL9RQuxMQ7aERoTtQzny6Fimp/PSJop/qyi02RfRt2QpXKY
c8bDxKHamMfbdh8zNZlHpxAE0m8OjDPqfj86ItIM7FbN6sN7N7wVholRICV3CRM3
GzTjK64vuIuhc6G9Uli2
=Nf0A
-----END PGP SIGNATURE-----

 

[Keith Thompson]

-----BEGIN PGP SIGNED MESSAGE----- [6 lines deleted]
-----BEGIN PGP SIGNATURE----- [16 lines deleted]
-----END PGP SIGNATURE-----

Do you have to include all that PGP baggage for a one line question?

For what it's worth, my newsreader recognized it as a PGP signature
and showed me only a single line. I'm aware that others don't do
this.

 

[Spiros Bousbouras]

It was pretty annoying actually. Can't you put this stuff in the
headers?

I find it annoying too. I have to scroll down a fair bit to get
to the continuation of the thread. Plus I have no idea how to
verify it even if I wanted to. It did prompt me to search on
the internet a bit but I didn't find any short explanation on
how it's supposed to work and I can't be bothered to read
a long explanation.

And how does it stop someone impersonating you? Anyone can add a dozen
lines of gobbledygook at the end of a message. *You* might be able to
tell it's a forgery, but surely you would know that anyway, unless you
have a really bad memory.

Very true. There is actually a philosophical side to this:
for me Falcon Kirtaran is just a name I encountered on
this group for the first time a few days ago so I can't
think of a way to define even in principle who the "real"
Falcon Kirtaran is or how to distinguish between the
real Falcon Kirtaran posting a message as opposed to
an impersonator. But perhaps he is interested in people
in his immediate environment being able to tell the
difference.

 

[Spiros Bousbouras]

If you knew how many attacks I
sustain on my network in a day, and how much hate mail I get (God only
knows why),

Because people get fed up with your signature perhaps?

 

[Guest]

Repeated addition is multiplication, repeated multiplication is
exponentiation, and so forth.  I've sometimes thought about a
hypothetical operator such that repeated <whatever> is addition,
but I was never able to come up with anything consistent or useful.

http://en.wikipedia.org/wiki/Knuth's_up-arrow_notation