From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Summary: make it right and THEN make it faster
Date: 07 Nov 92 00:12:40 GMT

( The topic seems to have drifted quite far from the "Subject:" 
  line, but I'll leave it alone. )

: From: bs@gauss.mitre.org (Robert D. Silverman)
: Message-ID: <1992Nov5.202412.7266@linus.mitre.org>
: Needless to say, there are people who have to worry about speed FIRST,
: and that other considerations are (almost) irrelevent.

: From: bs@gauss.mitre.org (Robert D. Silverman)
: Message-ID: <1992Nov5.203759.8030@linus.mitre.org>
: Dr. Rubin's main rule is:
:       "The code should run as fast as possible"
: For him, all other considerations are secondary. Who are you to tell
: him what his priorities should be?

Ah, Robert seems to be saying that Dr. Rubin is a member of that large
class of people for whom it is very very important to get the wrong
answer as soon as possible.  But wait.... if "The code should run as
fast as possible" and "all other considerations are secondary", why
doesn't he just run the null istream?

Since Dr. Rubin *doesn't* suggest running the null istream, I conclude
that the "(almost) irrelevant" above contains a very, very large point
swept under the rug.  It is of *primary* importance that the code be
correct.

Therefore I claim that the nits people have been picking have not been
empty nits.  The suggestions about maintanability and readability are
not wrong-headed.  They speak to the primary goal of the code: to get
the right answer.

And I am always very VERY skeptical that it is *ever* important to
"worry about speed FIRST" for code that does not constitute a
bottleneck.  Which, for any nontrivial system, is fairly sure in
practice to be in excess of 80% of the code.  And even for those
segments of code that need excruciating attention to speed, the
developer had better worry about *correct* *results* FIRST.

: There are times when readability, portability, and ease of maintenance
: are of primary importance. There are times when they don't matter at
: all. Stop pretending that they are the end-all of good coding.

I agree that readability, portability and maintainability can be
reasonably traded off against required speed.  But since readability 
and maintainability are so intimately related to getting the code to be
correct and then keeping the code correct, I find it impossible to
agree that there are *ever* times when these two "don't matter at all".

Now, with all that said, I must also say that I have a great deal of
sympathy with (what I take to be) Dr. Rubin's general position.
Optimizing cricical code in high-level languages usually feels like
trying to pick a lock while wearing welding gloves.  It would be very
nice if there were a way to just strip off those gloves and get down
and dirty with the generated istream.

But when the lock you are trying to pick is red-hot, you'll just burn
your hands that way.  And further, such hands-on features are
inherrently unportable, and hence are not standardized because they
*can't* be standardized.  You are wearing the welding gloves in the
first place because you're working with hot material, and the gloves
are how you deal with that. (That is, you are using a high-level
language because you are working with very complex and detailed
problems, and the high-level language is a standard way of dealing with
complexity.)  You can't expect glove manufacturers to put Yale or Slage
lockpicking features into every glove they sell, since not every welder
needs to pick locks, and even those that pick locks don't *all* work
on Yale or Slage locks.  It isn't economically feasible.

But don't get the idea that I think that high-level languages shouldn't
incorporate graceful fallback to low-level access to the underlying
implementation.  Just as I pine for smoothly integrated bit-level
access in source level debuggers, and often don't get it, I wish
language systems more often allowed better control over the generated
code for those cases where I'm sweating away in my welding gloves
poking at that annoying lock.  I just have empathy for how hard it
is to do such things right, and how unfair it would be for me to blame
the manufacturer of the welding gloves I'm using just because they
won't "do what I want" instead of what they were designed for within
the constraints of their resources and market.


Let me summarize it all in this way.  I think that television is
a vast wasteland.  But rather than repeatedly complaining that network
programmers don't program to suit me, I go and read books, play with
netnews, rent video tapes, and go to movies.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch,comp.lang.forth