Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!mintaka!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Common subexpression optimization
Message-ID: <14233@lambda.UUCP>
Date: 8 Feb 90 22:57:20 GMT
References: <838.18:06:33@stealth.acf.nyu.edu>
Lines: 56

From article <838.18:06:33@stealth.acf.nyu.edu>, by brnstnd@stealth.acf.nyu.edu:
> Piercarlo is entirely correct. If you care about ``information hiding''

"Information hiding" is NOT part of the subject matter of this thread
in the newsgroup.  We can talk about "information hiding" if you like,
but it is a different subject.  ("Information hiding" refers to various
scoping rules which allow codes to share data without making the data
_global_.  In C, 'static' variables which are declared at the beginning
of a file are shared by all the procedures within that file and are not
seen outside the file - THIS is a form of information hiding.)

On the other hand: if, by "information hiding", you really mean
"obfuscating code" - I can't think of a quicker way of doing it
than putting in the kinds of optimizations recommended by Peter
Grandi.

> [...]
> and the ``purity'' of your code more than efficiency, you can't expect
> fast code.

Agreed.  If clarity, correctness, and maintainability are more important
than speed, then simple, clear code is the proper choice.  However, I CAN
still expect better speed performance from a good compiler than from the
kind Peter Grandi recommends.  In fact, for the types of optimizations
that we have been discussing, modern compilers can be expected to do as
well as the hand optimized stuff.  There are, indeed, other types of
optimization which compilers cannot yet do (at least not well) - these
are the proper targets of programmer effort (if anything is).

> [...]       If you can't bear to put your original code in comments and
> write an efficient version with temporary variables, you don't deserve
> fast code.

Temporary variables aren't, necessarily, the best way to achieve
improvement.  As compilers get better, they may become even _more_
irrelevant.  Furthermore, fast code is _NOT_ the only criterion
for measuring the quality of the programming.  Everyone has heard
(or should have) of the 90%/10% rule - 90% of the execution time
is in 10% of the code.  Programmer effort in that 10% might be
cost effective.  But to try to optimize the last cycle out of the
whole code is almost certainly NOT cost effective.  Programmers
generally cost about $100-$200 a day!  If it takes a day to optimize
a procedure which saves an hour of SUN workstation time over the
life of the code - I've WASTED a couple of hundred bucks!

For MOST things, the important thing is to get the code written and
correct.  Speed is, almost always, a secondary consideration.  (This
is not to say that speed isn't important - it _usually_ isn't - but
when it is, it REALLY IS.  Unfortunately, when speed REALLY IS
important, it is usually more cost effective to switch directly
to assembly than to mess around with half-way measures in a high-
level language.  The speed sensitive code is usually a small part
of the whole program and can be recoded in assembly with gratifying
results.)

J. Giles