🚀 go-pugleaf

In article <4ianbt$h8m@solutions.solon.com>,
Michael J Zehr <tada@athena.mit.edu> wrote:
>In article <4i97ht$8gb@solutions.solon.com> Andrew Dalgleish <andrewd@axonet.com.au> writes:
>>I have found the magazine. In the December 1995 issue of C/C++ Users 
>>Journal is an article entitled "Another Slap at Lowly goto".
>>The authors compared the assembler output of 9 compilers, only Microsoft 
>>C 7.0 optimizes loops built from goto's. All the compilers did worse 
>>than I would have expected.

>>The authors came to the wrong conclusion - don't criticize the compiler, 
>>stay away from goto's. IMO this amounts to shooting the messenger.

>I would disagree with this.  The compiler writers should allocate their
>resources to optimize best for the most common code they compile.

What you are saying is that if someone finds a method of coming up 
with code which when intelligently compiled will run faster that the
compiler should not try to take that and compile it intelligently?

Are you saying that someone who can read a road map and find a
better way should then have the engine controller refuse to use
an optimal gas-air mixture?

>If someone wants to obscure what they are doing from the compiler
>(writing a loop with a goto instead of saying what they mean), then
>that's their choice.  But they shouldn't expect everyone else who is
>trying to be clear in communicating with the compiler to pay higher
>prices so the compiler writers can allocate more resources to a rare and
>avoidable circumstance.

Gotos are NOT obscure!  I have naturally occurring examples of goto-laden
code in which the control is straightforward; if you were not told what
it does, the slower structured version would not be enough for someone
without a knowledge of probability and random variable generation to deduce
anyhow.  The cost of the transfers is a large part of the total cost.

>It also slows the compilations down in the cases when someone is using a
>goto when it isn't a simple loop they're writing -- the compiler would
>have to check to determine the semantics to see if it could apply its
>optimzations.

If the compiler cannot optimize by itself, the programmer should be able
to interact with it.  This seems to be anathema to compiler writers and
language designers.  And when ways are suggested to get around some of
this, such as allowing programmers to present alternative modules, from
which the compiler can choose for the purpose of optimization, the answer
given is, "The compilers cannot handle such complications."  This is a
weakness of the compilers, not the programmers.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
hrubin@stat.purdue.edu	 Phone: (317)494-6054	FAX: (317)494-0558