Assembly Language

[chrisname]

Euphemisms aside, what "big object" are you expecting to increment? I don't see that you'd ever need to increment something bigger than an integer or pointer.

Also @Gaminic, I did post a reply to your post but my Internet connection decided to cut out randomly just before I clicked "Reply" (not realising I had no connection) so I lost the post. I can't really be bothered to type it up again to be honest...

[moorecm]

Arthar wrote:

But considering the other option, I'd still go with assembly. It's still useful for analyzing the assembler code generated by compilers.

This!

codekiddy wrote:

I would never spend even one minute of my life to learn visual basic.
not only because it's Windows only language but programs wroted in visual basic are crapy and unstable.

I have actually seem some pretty elaborate projects in VB. Not that I'm advocating it.

Gaminic wrote:

b) The link you posted specifically says it doesn't matter for intrinstic types like ints, which, again, was what you were talking about, which was what I disproved. If you're going to provide sources to support your side of the discussion, at least make sure they're actually supporting your side of the discussion. Also, just because it's on the internet doesn't mean it's [still] correct. Pull up your IDE and test it. You know, like I did, when I provided proof of the opposite.

Am I to believe that you tested every compiler in existence and concluded that ++i generates the same machine code as i++?

Gaminic wrote:

My world was rocked when I found out setting a variable to zero by xor-ing with itself is apparently faster than simply setting it to 0.

I thought that on modern CPUs this is no longer the case.

[codekiddy]

To be completly honest I don't realy give a flying f** about on wich side someone is and would someone belive about postfix/prefix performance difference or not.

just to put some examples which you may find interesting and to show that I'm not the only person who is saying the same thing:

http://www.idinews.com/peeves/prefixIncr.html
http://programmers.stackexchange.com/questions/59880/avoid-postfix-increment-operator
http://stackoverflow.com/questions/3541399/postfix-and-prefix-increment-operator-in-a-for-loop
http://thunderguy.com/semicolon/2002/08/13/prefer-prefix-operators-over-postfix/
http://stackoverflow.com/questions/3181211/prefix-postfix-increment-operators
http://www.devx.com/tips/Tip/12634

there are alot more articles on ++a/a++ preformance.
but I don't have willing to google them all now, do it your self and see.

now would someone belive or I dont care.

[moorecm]

I'll help you out:

Item 9. Don't pessimize prematurely.
Item 28. Prefer the canonical form of ++ and --. Prefer calling the prefix forms.
-- C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (2005) by Herb Sutter and Andrei Alexandrescu
Item 6. Distinguish between prefix and postfix forms of increment and decrement operators.
-- More Effective C++ (1996) by Scott Meyers

[codekiddy]

moorecm,
thanks alot for your sugestions of core things!
but I'm already on API design and have no willing to go back
let me help you out:
http://www.amazon.com/API-Design-C-Martin-Reddy/dp/0123850037

[rapidcoder]

the following code:

int a = b++;

can be expected to run slightly faster than this one:

int a = ++b;
no it can't be expected to run faster.

If you can't see something, doesn't mean it doesn't exist. You will find an explanation about why the former example is usually faster in probably any good book on modern processor architecture. Oh, even Wikipedia mentions this indirectly...

(in case you still don't catch it I give you a keyword to search on: pipeline stall.)

BTW: Most articles on Internet about postfix/prefix increments are wrong, because they use a simplified and incorrect program execution model, assuming the order of instructions in machine code does not affect performance, but only their number and type.

[Cubbi]

rapidcoder wrote:

I give you a keyword to search on: pipeline stall.

That is a good and useful keyword to search on, but it makes no difference for the code in question. It is exactly identical: it's a load, an addition (which depends on the result of the load), and a store to the same location (which depends on the result of the addition). The only difference is the name of the register that receives the result of the addition.

The code that follows, if it depends on the value of a, may in fact begin doing something useful with it while the addition is performed (e.g. in a multi-ALU core) or at least start going through the pipeline (as you hint) in the "slightly faster" postincrement case, but no such code was posted.

[rapidcoder]

The code that follows, if it depends on the value of a, may in fact begin doing something useful with it while the addition is performed (e.g. in a multi-ALU core) or at least start going through the pipeline (as you hint) in the "slightly faster" postincrement case, but no such code was posted.

This is pretty obvious. I would not be assigning a value not to use it later. The compiler is free to reorder instructions, and the postincrement gives it more room to do so. I said "it may be" considered slightly faster, not that it always is.

[Gaminic]

@moorecm:
Gah, stop extrapolating from my text by ignoring half of what I said.
I never made any claims of "i++ = ++i". I never made any claims of "compiler = compiler". All I said was "if i++ is used in a standalone statement, i.e. there is no side-effect/the 'old value' is not used, there is no reason to assume a compiler would implement it any other way". codekiddy will get angry at me for using a "too simple example", but considering that it is the only case I'm talking about, I feel I have every right to use it:

int a = 5;
a++;
++a;

Considering nothing is done with 'a' except incrementing it, there is no reason to assume a compiler would generate different code for both operations, because it wouldn't make sense. It's the most simple optimization imaginable, and it's very frequent because it appears in so many for loops. I should have said "I verified this with my compiler" instead of using the word "proof", but considering the simplicity of the case, any compiler that doesn't properly optimize it is probably not a very good compiler anyway.