It is more than a dispute over definitions of terms?
Update: (One) spelling correction made.
Most emphatically yes!
If all expressions that could contain an opportunity for parallelism were simple expressions (operand1 op operand 2), then you would be correct that undefined EO wouldn't matter--but they are not.
Once the expression is a compound expression, the defined EO is required to allow the programmer to construct the single expression that retains the parallelisable operation, whilst having control over any subexpressions that must be rendered before that parallelisation can occur.
If the only recourse the programmer has to ensure the order of evaluation, is to break up the expression into separate statements, then the opportunity for parallelism is lost.
You have to look at the entire picture. Without extra syntax, separate statements means serialisation. Compound expressions permit concurrency without extra syntax. But for that to succeed, the programmer need to be able to know exactly what the result of the compound expression will be--for sure. No ifs and buts--otherwise how can he make the required guarentee that "there are no side-effects, or if there are, I know they will do the right thing"?
He can only make that guarentee if he knows that the compiler will do exactly what he has programmed--not arbitrarially decide to reorder parts of the compound expression,
And the bottom line is--nothing is lost by EO being defined.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco.
Rule 1 has a caveat! -- Who broke the cabal?
|