17

This was an interview question. I said they were the same, but this was adjudged an incorrect response. From the assembler point of view, is there any imaginable difference? I have compiled two short C programs using default gcc optimization and -S to see the assembler output, and they are the same.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
Fandango
  • 305
  • 3
  • 9

6 Answers6

20

The interviewer may have wanted an answer something like this:

i=i+1 will have to load the value of i, add one to it, and then store the result back to i. In contrast, ++i may simply increment the value using a single assembly instruction, so in theory it could be more efficient. However, most compilers will optimize away the difference, and the generated code will be exactly the same.

FWIW, the fact that you know how to look at assembly makes you a better programmer than 90% of the people I've had to interview over the years. Take solace in the fact that you won't have to work with the clueless loser who interviewed you.

Kristopher Johnson
  • 81,409
  • 55
  • 245
  • 302
  • 3
    That's true from the assembly point of view, but all x86 processors would do the same for both instruction sequences - inc [memadr] requires loading the value to a hidden register anyway. However different amount of code would be emitted. – sharptooth May 15 '09 at 09:21
  • 1
    I'd expect a decent compiler to see that it's the same i in the LHS and RHS and produce the same code. – Nathan Fellman May 15 '09 at 14:13
  • 2
    Won't a modern SSA compiler rewrite the entire statement anyway? The first statement becomes i_2=i_1+1 and the second becomes i_2=i_1+1, too. Chances are that the i_1 and i_2 variables aren't assigned the same register. – MSalters May 15 '09 at 14:56
  • 1
    For `int i`, if your compiler produces sub-optimal asm for either of these statements (with optimization enabled of course), it's a bug and should be fixed. The compilers we care about for mainstream ISAs (gcc, clang, MSVC, ICC) are fine. There's no reason to expect this C statement to compile to any specific asm: depending on surrounding code loops can get unrolled, or an increment can be folded into some other operation. – Peter Cordes Dec 28 '19 at 10:08
  • 1
    They're not the same for `_Atomic int i`, but that's basically like C++ with overloaded operators. – Peter Cordes Dec 28 '19 at 10:08
10

Looks like you were right and they were wrong. I had a similar issue in a job interview, where I gave the correct answer that was deemed incorrect.

I confidently argued the point with my interviewer, who obviously took offence to my impudence. I didn't get the job, but then again, working under someone who "knows everything" wouldn't be that desirable either.

spender
  • 117,338
  • 33
  • 229
  • 351
  • 3
    It's worth arguing - I had the same experience, pointed out where and why the interviewer was wrong, and got the job. –  May 15 '09 at 09:18
  • 2
    Agreed. It's always better to give correct answers than the one you think the interviewer wants. Good interviewers will want to hire people who are smarter than they are. – Kristopher Johnson May 15 '09 at 09:20
8

You are probably right. A naive compiler might do:

++i to inc [ax]

and

i = i + 1 to add [ax], 1

but any half sensible compiler will just optimize adding 1 to the first version.

This all assumes the relevant architecture has inc and add instructions (like x86 does).

cletus
  • 616,129
  • 168
  • 910
  • 942
  • I'd have made a comment like this in the interview. That ++i would definitely use an increment instruction if available, whereas i = i + 1 may not do so in a naive compiler but should be optimised to do the same by a decent compiler. – workmad3 May 15 '09 at 09:18
  • using the ++i shows you know the difference. It's always a good habit to try say what you actually mean. – Chris Huang-Leaver May 15 '09 at 09:22
  • 1
    it's worth noting that ++i (or i++, or i=i+1) doesn't always map to the `inc` instruction. If i is a pointer to an int then ++i will be the same as add i, 4, because i needs to point to the next int, which is 4 bytes wide. If i points to a long, the ++i will be the same as add i,8, for the same reason. – Nathan Fellman May 15 '09 at 14:21
  • @Nathan: excellent point. If i is a pointer, the statements will probably compile to the same code cos, for example, double *p = 0; p++; p now equals 8. – cletus May 15 '09 at 14:47
  • Both assembler ops are invalid, square brackets implies access a memory slot via AX. Theres is also no inc ax instruction - one must use add 1 to AX. – mP. May 15 '09 at 09:20
  • @mP. Both are correct. inc [ax] means increment the memory addressed by ax, while inc ax means increment ax itself. – Nathan Fellman May 15 '09 at 14:16
  • `[ax]` isn't a valid 16-bit addressing mode. `[bx]` is, and `[eax]` is a valid 32-bit addressing mode. Anyway, fun fact; `add [mem], 1` is one case where `add` *is* more efficient than `inc` on modern Intel CPUs. [INC instruction vs ADD 1: Does it matter?](//stackoverflow.com/q/36510095). But if the asm output of your optimizing compiler depends on this source difference, your compiler is broken (missed-optimization bugs). Using peepholes like `inc` (or not when they're actually slower) is something the compiler back-end should do on its own. – Peter Cordes Dec 28 '19 at 10:11
7

To defend the interviewer, context is everything. What is the type of i? Are we talking C or C++ (or some other C like language)? Were you given:

++i;
i = i + 1;

or was there more context?

If I had been asked this, my first response would've been "is i volatile?" If the answer is yes, then the difference is huge. If not, the difference is small and semantic, but pragmatically none. The proof of that is the difference in parse tree, and the ultimate meaning of the subtrees generated.

So it sounds like you got the pragmatic side right, but the semantic/critical thought side wrong.

To attack the interviewer (without context), I'd have to wonder what the purpose of the question was. If I asked the question, I'd want to use it to find out if the candidate knew subtle semantic differences, how to generate a parse tree, how to think critically and so on and so forth. I typically ask a C question of my interviewees that nearly every candidate gets wrong - and that's by design. I actually don't care about the answer to the question, I care about the journey that I will be taking with the candidate to reach understanding, which tells me far more about than right/wrong on a trivia question.

Community
  • 1
  • 1
plinth
  • 48,267
  • 11
  • 78
  • 120
  • That's intellectual property. – plinth May 25 '09 at 17:49
  • What exactly do you think the difference is with `volatile int i`? Those both compile the same with most compilers. The C standard / as-if rule doesn't specify anything about doing a memory-destination increment with a single instruction (atomic wrt. interrupts but not other cores). GCC *does* miss the optimization of doing `++i` or `i=i+1` with a single memory-dst instruction for x86 with `volatile`, but clang does it for both volatile and non-volatile: https://godbolt.org/z/j46qGF. So with both compilers, there's still no difference between `++i` and `i=i+1`, only for volatile vs non – Peter Cordes Dec 28 '19 at 10:20
  • Is there an embedded compiler where `volatile` makes `++i` a lot different? – Peter Cordes Dec 28 '19 at 10:21
3

In C++, it depends if i is an int or an object. If it's an object, it would probably generate a temporary instance.

Johan Kotlinski
  • 25,185
  • 9
  • 78
  • 101
0

the context is the main thing here because on a optimized release build the compiler will optimize away the i++ if its available to a simple [inc eax]. whereas something like int some_int = i++ would need to store the i value in some_int FIRST and only then increment i.

NK47
  • 21
  • 1