🚀 go-pugleaf

In article <PCG.90Feb5185112@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes:
>   Strength reducers are good enough that I don't need to mess
>   with pointer variables. Various forms of redundancy elimination
>   are good enough that I needn't bother about every little common
>   subexpression.  Vectorizers are good enough so that I need not
>   manually insert vector primitives.  Register allocators are
>   good enough that I need not scatter register declarations about.
>
>About the "good enough" I am somewhat skeptical (especially about
>the register allocators -- but then again, many modern machines
>have more registers than variables...). Also, most of the time
>these optimizations are irrelevant.

Interesting assertion -- do you have references to support this?
Especially, do you have evidence that vectorization is usually
irrelevant?

>It [optimization] encourages less precise coding, and makes the
>compiler many times larger, and these are *very* bad news, and very
>costly too.  All this to optimize very little pieces of code, which
>could be manually sorted out, and with improvement on their
>information content for both humans and programs that read them.

(1) Large costly compilers are only "bad news" if few programs are
developed -- once a compiler is widely used, the extra time spent in
its development is paid back many times over.  (Of course, first you
have to get the compiler into wide use.)

(2) Why do you assume that "precise coding" is good?  Does it get a
program written more quickly, or make the program more maintainable,
or more likely to be correct, or increase its portability?  In
general, the answers are NO, NO, NO, and NO.  At best, "precise
coding" will make code run faster on one machine with one particular
compiler.  A good optimizing compiler can do just as well, with less
time spent doing it.  (Note -- you perhaps regard optimizers as
program-manglers; for C, you have no grounds for complaint, since
(last I heard) the language standard is not yet official -- if you
program in a language with no official definition, you should expect
some variation in the implemented semantics.  Nobody forced that
choice on you.)

A high-powered optimizer does allow programmers to get a program
running efficiently with less time spent thinking about it.  This is
bad?  We should program more slowly?  *Some* people use the extra time
to worry about higher-level issues, like correctness and algorithmic
complexity.  Some programmers aren't that thoughtful -- would you
trust such a person to hand-optimize code?

David