Re: looking for thoughts on the philosophy of optimizing compilers

On 6 May, 19:25, Chris Friesen <cbf...@xxxxxxxxxxxxx> wrote:
Spiros Bousbouras wrote:
On 6 May, 18:02, Eric Sosman <Eric.Sos...@xxxxxxx> wrote:
Chris Friesen wrote:

Here are a couple of examples:
1) Removal of a hardcoded busy-wait. This loop has no side effects, so
the compiler removes it entirely.
for (int i=0;i<1000000;i++)
continue;
Good for the compiler! say I.

Bad for the programmer say I. I have encountered situations
where the only way to get the exact delay I wanted was through
such loops. But I wouldn't use the continue.

On most processors there should be a clock cycle counter or timestamp
counter that could be read instead of relying on the compiler to not
optimize.

How many desktop platforms have you encountered where you have
access to such a counter from a C programme possibly using
operating system specific functions? <OOT> On POSIX at least the
function with the smallest time granularity I know of is
nanosleep() and it hasn't always given me the precise delay I
wanted. POSIX adds a lot to the C standard. If it still doesn't
give you direct access to a clock cycle counter it goes to show
that sometimes you need such loops, as ugly as they are. </OOT>

Code like this *should* be removed,
not only by the optimizer but also by any programmer who sees it in
the source.

Certainly not by the optimizer unless we're talking about some
seriously advanced AI. A human programmer should investigate
further before removing it.

The code has no side effects visible to the rest of the program (as
defined by the language model), so the compiler is free to remove it.

According to the standard yes, it's free to remove it. But when
Eric said that it "*should* be removed" I took it to mean from a
QOI point of view and I was replying in the same spirit. From a
QOI point of view I say it should *not* be removed.

In fact, a sufficiently advanced CPU could recognize that there are no
side effects and optimize it away.

Well, I hope if such an advanced CPU ever gets created it should
have instructions to specify that some code should not be optimised
away.

Arguably a human programmer should replace it with code that behaves as
intended rather than removing it or leaving it.

A human programmer should try and decide if the intention of the
previous programmer was to place a delay at that point in the
code. If that was indeed the intention then the code is correct
as written and it should neither be removed nor modified (unless
of course the new programmer can think of a better way to
achieve the same effect).
.

Relevant Pages

  • Re: [EGN] Hoisting Loop Invariants (Was: Re: [EGN] Numerical Accuracy)
    ... compiler out there somewhere that did as you claim. ... > the programmer has this knowledge, then the programmer should not use ... >> string in a loop, regardless of the blatant inefficiency of doing so. ...
    (comp.programming)
  • Re: The Philosophy of Programming?
    ... A compiler is free to ... >>is to allocate on entry to almost any block. ... > int foo{ ... But any programmer who wants to be more than a coder prefers, I think, ...
    (comp.programming)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... the compiler doesn't have the free pass to /assume/ that the function ... Nobody has recommended doing all optimization by hand to my knowledge. ... Compiler behavior in optimization simply has no place in a language ...
    (comp.programming)
  • Re: Static/Strong/Implicit Typing
    ... and every programmer would instantly revere the static type analysis. ... will inform your compiler of your construction. ... the two varieties and consciously break the type disjointness. ... Common Lisp is not quite as abstract, ...
    (comp.lang.lisp)
  • Re: Can someone spot the error here?
    ... the compiler can and should assume ... but the programmer is at option to ... a language like Pascal is founded on. ... Wirth was looking both to compiler efficiency, ...
    (comp.lang.pascal.misc)