On 03.07.2012 21:27, Kinkie wrote:
Usually the other ++ works better in readability
conn_->getPeer()->stats.conn_open++;
or even
conn_->getPeer()->stats.conn_open += 1;
With GCC this code:
15 int a=0;
16 a++;
17 ++a;
18 a+=1;
gets assembled as:
16 a++;
=> 0x0804873c <main(int, char**)+168>: 83 44 24 18 01 addl
$0x1,0x18(%esp)
(gdb)
17 ++a;
=> 0x08048741 <main(int, char**)+173>: 83 44 24 18 01 addl
$0x1,0x18(%esp)
(gdb)
18 a+=1;
=> 0x08048746 <main(int, char**)+178>: 83 44 24 18 01 addl
$0x1,0x18(%esp)
That matches what the recent blog post benchmarks are saying.
Con:
* Modern compilers are able usually to optimize all forms
automatically to one instruction.
* when they optimize to 2 instructions, those are usually run in
parallel by the CPU optimizations anyway.
* +=1 is sometimes (when?) benchmarked as faster than both by about 2x
the difference between the ++ themselves.
* C++11 compilers contain a lot of optimizations (like auto-merging
these) which dwarf these manual benefits.
Pros: (apparently)
* -O0 builds apparently have some difference, (but then does anyone
care with -O0?)
* its easier to code a pre-increment operator on custom classes than a
post. (do we care?)
* pre-increment on compound objects does not undergo auto-magical
conversion to operator+=() by default. Apparently post-increment does.
* there is apparently still a difference on some less common CPU
architectures. PowerPC was brought up as an example. No mention of ARM,
so I'd be interested to know if ARM has any difference.
IMO,
* This last two pros appear to make it still worthwhile for portable
software like Squid. For now.
* this is the type of minor optimization that we should accept as it
comes, but not waste time arguing over (or obfuscating the code to
achieve!). It's too small an optimization to be worth the trouble.
* my point about "++conn_->getPeer()->stats.conn_open" is solely down
to readability. Which is trivially resolved by "++(x)", with brackets
around the symbol being incremented. Using bracketing just for clarity
covers all sorts of borderline expressions which appear obfuscated at
first glance.
Amos
