6

It is a known fact that argument evaluation order in c and c++ are not defined: for example: foo(a(),b()) In the above call it is up to the implementation of the compiler to decide which order of evaluation to pick and hence forth which function to execute first. Lately one of my friends asked why is the order of evaluation unspecified in C or C++. When I googled it, I came to know that specifying an evaluation order would lead to sub-optimal code generation. But how is it so? Why would a defined order of evaluation of arguments lead to sub-optimal code? And when I referred to Java's argument evaluation order. I found the following in the spec.

15.7.4. Argument Lists are Evaluated Left-to-Right

In a method or constructor invocation or class instance creation expression, argument expressions may appear within the parentheses, separated by commas. Each argument expression appears to be fully evaluated before any part of any argument expression to its right. If evaluation of an argument expression completes abruptly, no part of any argument expression to its right appears to have been evaluated?

That being the case, Java has a defined argument evaluation order, but saying C or C++ compilers would yield sub-optimal code if such a behavior is specified seems a little odd. Can you throw some light on this?

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
sasidhar
  • 7,523
  • 15
  • 49
  • 75

4 Answers4

9

It's partially historical: on processors with few registers, for example, one traditional (and simple) optimization technique is to evaluate the subexpression which needs the most registers first. If one subexpression requires 5 registers, and the other 4, for example, you can save the results of the one requiring 5 in the register not needed by the one requiring 4.

This is probably less relevant that usually thought. The compiler can reorder (even in Java) if the expressions have no side effects, or the reordering doesn't change the observable behavior of the program. Modern compilers are able to determing this far better than compilers twenty or more years ago (when the C++ rule was formulated). And presumably, when they aren't able to determine this, you're doing enough in each expression that the extra spill to memory doesn't matter.

At least, that's my gut feeling. I've been told by at least one person who actually works on optimizers that it would make a significant difference, so I won't say that I'm sure about it.

EDIT:

Just to add some comments with regards to the Java model. When Java was being designed, it was designed as an interpreted langauge. Extreme performance wasn't an issue; the goal was extreme safety, and reproduceability. Thus, it specifies many things very precisely, so that any program which compiles will have exactly the same behavior regardless of the platform. There was supposed to be no undefined behavior, no implementation defined behavior, and no unspecified behavior. Regardless of cost (but with the belief that this could be done at reasonable cost on any of the most widespread machines). One initial design goals of C (and indirectly C++) was that unnecessary extra runtime cost should be minimum, that consistency between platforms wasn't a goal (since at the times, even common platforms varied greatly), and that safety, while a concern, wasn't primordial. While the attitudes have evolved some, there is still a goal to be able to support, efficiently, any machine which might be out there. Without requiring the newest, most complex compiler technologies. And different goals naturally lead to different solutions.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • there are also cases where you e.g. fetch the memory for argument 3, and then calculate the values of args 0,1,2 and when done, memory for argument 3 has arrived. – PlasmaHH Jul 12 '12 at 10:59
  • @PlasmaHH Good point. But in all such cases, I think the compiler should be able to determine that it doesn't affect the "observable behavior". – James Kanze Jul 12 '12 at 11:26
  • so in essence if the C and C++ compilers were more brilliant and used modern machines then they too would have a defined order of argument evaluation?? – sasidhar Jul 12 '12 at 11:34
  • @sasidhar Possibly some compilers do. But the standard doesn't require it, so the compiler writers don't make any particular effort to ensure it. – James Kanze Jul 12 '12 at 11:37
  • @JamesKanze: It sure could, but what if would affect observable behaviour (e.g. because the computation stores a new value)? then it could not apply that optimization. C and C++ made the tradeoff to allowing that optimization. – PlasmaHH Jul 12 '12 at 14:29
  • @PlasmaHH If the compiler is unable to determine whether it affects observable behavior, then it cannot apply the modification. My gut feeling is that with modern compiler technology, any time the compiler is unable to determine this, there are enough other things occurring that this one difference won't be significant. But that's just a gut feeling---I haven't actually written an optimizer to verify. – James Kanze Jul 12 '12 at 15:18
3

Java posits a stack-based virtual machine, in which there is no advantage to reordering operands. As per James Kanze's answer, C and most fully compiled languages posit a register architecture, in which register 'spills' to memory are expensive and are greatly to be avoided, so it can be better to reorder the operands, indeed to do all kinds of things, to maximize register usage and minimize spillage.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Not really the point. After all the JIT has to follow the JLS too and that compiles down to registers for most architectures. Same possible advantage there if it was allowed, but I doubt it's anywhere near noticeable. Either the functions are inlined in which case the compiler can reorder anyhow apart from real race conditions or they're large enough or unknown that the compiler will probably not look into them anyhow (well with IPO it may make a difference). – Voo Jul 12 '12 at 12:44
  • @Voo The point is what was on the minds of the designers at the time the language was designed. – user207421 Jul 12 '12 at 13:04
  • Hmm could be, not sure whether JITs were already on the table when the first drafts were created. I'd think so, but considering the time it took for the first JITs to appear that really may have come later. – Voo Jul 12 '12 at 13:08
  • @Voo The first JITs were commercial products, that could not and would not have appeared before Java was released, and Java was designed well before it was first released. – user207421 Jul 12 '12 at 13:14
  • Doesn't mean that the designers didn't think about the effects of the specification on possible performance optimizations. JITs weren't new back then and the fact that interpreted code is not the fastest certainly wasn't a big surprise either. E.g. back then multithreaded code was extremely unusual and they still wrote the spec in such a way that you could well optimize the code in the face of multiple threads. – Voo Jul 12 '12 at 13:26
  • @Voo And yet they came up with a stack model and a left-to-right operand evaluation rule. – user207421 Jul 12 '12 at 13:28
  • The stack architecture was certainly not their best decisions (although that became clear only much much later), but the reasons to go with left-to-right evaluation are imo more due to not confusing programmers for rather minor performance gains. – Voo Jul 12 '12 at 13:30
  • The difference between Java and C/C++ here is simple. When Java was being designed, the designers felt that the performance of modern machines was sufficient to allow additional safety, even at some (probably very moderate) cost to runtime. One of the design goals was that any code which compiled would execute with the exact same results, regardless of the platform or compiler. If you execute `f() + g()`, `f()` has side effects, and `g()` throws, then the order of evaluation affects the observable behavior. So it must be defined. – James Kanze Jul 12 '12 at 15:22
1

I think we overanalyse it. The true answer is probably that in olden days before the C standard when K&R was the de facto standard, nobody bothered to specify which order to evaluate the arguments in and different compiler implementations went in different ways.

The logical way from a human point of view is to evaluate the arguments from left to right (as Java does it). The easy way, from the compiler's point of view is to do the argument evaluation from right to left. This is so that, once an argument has been evaluated, it doesn't need to be saved anywhere, it can be pushed on the stack ready for the call. Most C implementations that use the stack for arguments need to push them in reverse order. This is because K&R C has no way for a compiler to figure out how many arguments a function takes if it has not been defined in the same source file and programmers used to take advantage of that to provide a primitive form of variadic functions.

So the standard writers were faced with a choice of doing it the "right" way (left to right) and possibly breaking a lot of code or doing it the way most of the extant compilers did it and possibly breaking some other code or sticking with the status quo and letting the compiler designers choose what to do.

That's my opinion anyway, not based on any facts.

JeremyP
  • 84,577
  • 15
  • 123
  • 161
0

Not for the function evaluations as of for your example, but for simple expressions the two expression can even be executed in parallel. Modern architectures are pipelined and it can be more efficient to feed two pipelines (almost) simultaneously such that the operations that have to be performed overlap.

Also you seem to be under the impression that there are only two expressions to evaluate for the arguments, but there are four: a, b, a() and b(). The partial order for the function call in total is from left to right

    a -- a()
             \
         f --- f(a(), b())
             /
    b -- b()

As you can see from the picture there is a lot of potential parallelism and modern compilers can gain something by not having a prescribed evaluation order.

Edit: In view of the discussion some additional details. If a() and b() are function calls there is a guarantee by the standard that these function calls will not interleave, even if the functions are inlined. So then the picture above should have an addition constraint that a() and b() must be somehow ordered. (I don't know how to put that in the picture.)

If on the other hand they are other expression, e.g macro evaluations, these expressions may (and probably will) be interleaved if there is a gain.

Jens Gustedt
  • 76,821
  • 6
  • 102
  • 177
  • if C compilers start using parallelism like this, then shouldn't the code in `a()` and `b()` be thread safe? Generally when writing a C code we do not have much of parallelism in mind right? – sasidhar Jul 12 '12 at 12:35
  • We can only execute the two functions in parallel if the compiler's absolutely sure there are no race conditions (otherwise we may end up with a funny mixture of state, which c also doesn't allow). And if the compiler can figure that out, it could evaluate the functions in parallel anyhow I'd think. – Voo Jul 12 '12 at 12:49
  • @Voo from when did C compilers start figuring out that?? threading concept is not at the heart of C. It can only be implemented by using a library right? – sasidhar Jul 12 '12 at 13:04
  • @sasidhar If both functions are small enough they will be inlined and then the usual optimizations including reordering can happen (and we can autoparallelize code as well, as long as the result is valid under the c model). In that case the two functions are quasi executed in parallel (at least intertwined) if it gives an advantage. In the general case? There's IPO but no idea how well that works for this - I'd assume not well. – Voo Jul 12 '12 at 13:07
  • Not only race conditions in the typical sense. C guarantees that between the two calls `a()` and `b()`, each one sees either all the side effects of the other, or none of the side effects. This also has implications on code which runs in another thread and might see the effects of a and b, as long as its access to those effects is synchronized in some way. – R.. GitHub STOP HELPING ICE Jul 12 '12 at 14:03
  • @R This even has implications in a single threaded environment. Modern compilers are capable of interleaving instructions of two different functions. The question was actually posed to the C committee at one point, whether such optimizations would be legal. – James Kanze Jul 12 '12 at 15:35