NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/arch/10505

Internet Message Format | 1992-11-08 | 4.1 KB

Xref: sparky comp.arch:10505 comp.lang.misc:3541
Newsgroups: comp.arch,comp.lang.misc
Path: sparky!uunet!usc!sdd.hp.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Message-ID: <[e-mail]>
Organization: Purdue University Statistics Department
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 7 Nov 1992 12:55:41 GMT
Lines: 67

In article <[e-mail]> [e-mail] (Wayne Throop) writes:

>: From: [e-mail] (Robert D. Silverman)
>: Message-ID: <[e-mail]>
>: Needless to say, there are people who have to worry about speed FIRST,
>: and that other considerations are (almost) irrelevent.

>: From: [e-mail] (Robert D. Silverman)
>: Message-ID: <[e-mail]>
>: 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.

Now where did you get the idea that either of us wants an incorrect
routine?  Of course it is important that code be correct.  However,
program?  Of course, code to be useful should be correct, but I suspect
that every operating system has some essential bug in it; Murphy's Law
applies to computer programming.  However, any errors in the code I
posted were not due to my use of gotos, or code rearrangement to gain
performance.  One of my respondents suggested that I post to the net
a long explanation of how the algorithm was derived, and that will be
done next week.

Certainly code should be checked in whatever way possible for correctness.
In principle, the code I have posted could be so checked by setting up a
good trace program, feeding in random numbers of a higher quality than I
know how to get, and running it more than 10^20 times.  This would be more
than 10^13 of Dr. Silverman's MIPS-years; it cannot be done.  So I am
required to make a proof of correctness by investigating that the code
follows the algorithm.

But it is quite possible to speed up the flow of the code, and in parallel
remove the bugs.  This is not all that different from what language designers,
compiler writers, and hardware designers do.  Designing for the goal does not
mean that all the implementation bugs are removed first; this cannot even be
done, as any change may introduce bugs.  The particular code I posted is not
tailored for a specific machine; hardware can cause things to be done in a
different manner, and what is essentially the same algorithm should be done
somewhat differently on different machines, such as vector and parallel
processors.  The results will be different, so that that method of comparison
cannot be used.

As far as readability, portability, and ease of maintenance are concerned,
the code I have posted is quite portable.  The most readable version was
the one which had ONLY gotos for control; this got the most responses,
both to the net and by email, and these responses were quite accurate,
even the ones which would have slowed down the operation of the compiled
version.  Part of the reason is that I find the logic of the goto quite
simple, and I suspect that even those who condemn it do so for reasons
other than understandability of what it means.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)