Re: Don't trust your optimizer :-)
On 11/18/2010 03:08, Joshua Maurice wrote:
On Nov 16, 6:03 am, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
I assume this refers to the endless loop case, right?
Yes. Odd that it munged the link. Let me try again:
http://groups.google.com/group/comp.std.c++/browse_thread/thread/fb0f396824b9a801#
In case it munges it again, here's the header:
Newsgroups: comp.std.c++
From: Joshua Maurice<joshuamaur...@gmail.com>
Date: Tue, 21 Sep 2010 11:41:03 CST
Local: Tues, Sep 21 2010 9:41 am
Subject: Defect Report: non-terminating loops should not be undefined
behavior
<nod> I got that, but I was asking for a complete example that is as
simple as possible, preferably by code. In this discussion it is
essential that no hand-waving arguments are involved.
AFAIK, this is the case for C++98
and C++03. However, the wording has been changed in some of the newer
drafts, much to the dismay of many on these boards, including myself.
Specifically, one of the new C++0x drafts specifically says that the
compiler /can/ optimize away endless loops, such as:
for (;;);
Well, this is correct as written, because the loop alone does not induce
observable behavior. Can you give a more specific example program that
would demonstrate such a difference and that would also show that these
rules have negative aspects? For the discussion assume that the most
recently approved constraints would hold as addition to 1.10:
<quote>
The implementation is allowed to assume that any thread will eventually
do one of the following:
* terminate,
* make a call to a library I/O function,
* access or modify a volatile object, or
* perform a synchronization operation or an atomic operation.
[ Note: This is intended to allow compiler transformations, such as
removal of empty loops, even when termination cannot be proven. ? end note ]
</quote>
and assume a strike of the current 6.5p5.
Thanks for the most up to date wording.
I think my points in the other thread can be summed up as:
C++ inherits a lot of its design goals from C. C is a portable
assembly language, or at least C is meant to be portable, and to be
cost competitive with hand written assembly. C++ shares this design
goal: C++ should be portable, and when used correctly it should be
cost competitive with hand written assembly.
Let me insert here, that C++ is not going this new way alone. It does so
"hand-by-hand" with C1x. If you check out the most recent C1x draft,
n1526, you will find similar wording in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1516.pdf
6.8.5/6:
"An iteration statement that performs no input/output operations, does
not access volatile objects, and performs no synchronization or atomic
operations in its body, controlling expression, or (in the case of a for
statement) its expression-3, may be assumed by the implementation to
terminate.(Footnote 155: This is intended to allow compiler
transformations such as removal of empty loops even when
termination cannot be proven.)"
If the new
"infinite loop" rule was used by a compiler when the programmer did
not intend so, then you could result with a program with entirely
unpredictable behavior aka undefined behavior. Arguably, such cases
would be rare, but that's no excuse for a rule that says "If the sum
of any addition is 237404, then the program has undefined behavior."
Can you please provide a specific code example that demonstrates this?
Finally, it's a code level breaking change from the past standard.
I'm not yet convinced that this is true, given the definition of
observable behaviour and the lack of progress guarantees in C++03.
True infinite loops without "side effects" exist in a very small
subset of legitimate programs. An example given in some thread was a
signal driven program. main was simply:
int main() { for (;;); }
Some signal handlers weer installed, and all of the interesting work
was done in those signal handlers.
Obviously this means that
int main() { for (;;); }
is not a complete example program that demonstrates the defect. Can you
please provide one? Note that a conforming signal handler is required to
perform modifications on either volatile
sig_atomic_t or on lock-free atomic objects, which are explicitly
excluded in above optimization allowance.
Infinite loops without "side effects" exist frequently in testing.
I've found myself resorting to them frequently enough to be troubled
by this new rule.
There is a whole class of infinite loops which might exist in code as
a bug. On one implementation, it might be entirely removed, but on
another it might remain as an actual infinite loop. This allowance
would hide the existence of the bug with some probably random
behavior, or perhaps sensible behavior. I don't like things which
further hurt the portability of C++ code.
Again, hand-waving is not enough, we need something specific to discuss.
Note that above wording does not directly say in a normative form that
every empty loop can be optimized away.
So, what are the pros? Some hand-waived optimization opportunities as
far as I can tell. Can anyone actually present a plausible example
which would occur in real code? It's easy enough to construct a fake
example, but then it's a fake example, so the performance gains are
minimal. A fake example does not demonstrate a great performance gain
which I claim is required to introduce these completely non-obvious
semantics to the otherwise (mostly) sane C++ programming language. The
catch goes both ways: either the loop is "important" enough that it
cannot be optimized away, or it's "trivial" enough that it can be. It
seems to me that such trivial loops are very rare, and thus very
little performance gains will occur in practice.
As I understand it, a supposed big gain of this approach is to allow
the compiler to reorder a read or write from before the loop to after
the loop, or vice versa. This could be used to then allow further
optimizations, like common sub-expression elimination, and so on. This
seems a tad promising, though I would greatly prefer a real life
example. At this moment, it's my strong inclination that any supposed
benefits would not make up for all of the cons mentioned above.
Again, if I'm wrong, please correct me, preferably with a non-
contrived counter-example.
Well, counter examples are much easier to provide. A simple program that
you wrote as
int main() { for (;;); }
can optimize away the end-less loop. This is not what you want to hear,
I guess. To signal that the core language groups of both C and C++ are
going in the wrong direction when imposing this, we need a simple
counter example that can be forwarded to these groups.
No-one is intending to break reasonable programs: The standard
committees are not a group of "crazy scientists" that just invent
wording because they find these funny enough to print them in stone. The
compiler implementors involved try to *satisfy* the needs of their
customers, i.e. us, the programmers. Sometimes the selected wording does
have unwanted side-effects that could be interpreted in a way that would
not be helpful. By asking you for at least a single example I'm trying
to find such boo-boos such that it can be forwarded as early as possible
to the corresponding working groups.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]