NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/arch/10987

Internet Message Format | 1992-11-20 | 5.4 KB

Xref: sparky comp.arch:10987 comp.lang.misc:3827
Newsgroups: comp.arch,comp.lang.misc
Path: sparky!uunet!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, 21 Nov 1992 14:48:43 GMT
Lines: 95

In article <[e-mail]> [e-mail] (Wayne Throop) writes:
>: From: [e-mail] (Matt Kennel)
>: Message-ID: <[e-mail]>
>: The point, is, he [..Herman Rubin..]
>: wants a high-level real language, with real optimizers,
>: that nonetheless, does not consider hardware dependence to be anathema.

>Except that when such capabilities are pointed out, he sneers at
>them, and then asks for something else.  For example, gcc can generate
>inline procedures with assembly instructions interspersed.  For pointing
>this out, people get sneered at, and told that the notation isn't
>simple enough.

Working in a university environment does produce some problems, which
those with reasonable manpower support do not seem to realize.  I can
get gcc on some machines, but we do not yet have it on the one I am
supposed to use for production.  Also, it cannot be used for program
design for more than one machine, which is something I am supposed to
be involved in.  This is a major reason for asking for a good macro
translator, to isolate the dependent problems from the independent
ones and still be able to communicate.  I cannot reasonably communicate
SPARCstation program to someone using an RS/6000 or a CRAY Y-MP, but I
can communicate the algorithm to a mathematician using any one of those
machines in such a way that a language hacker could come up with good
code in consultation.

>When solutions to notation problems are presented, such as introducing
>operators into gcc by the usual lex and yacc notations, or by
>preprocessing with the TXL system mentioned by Matt a bit later, people
>get sneered at, and told that specifying syntax in these ways is
>too difficult.

As far as I can tell, TXL is a very new product.  I will not be able to
access it until our systems people decide it is safe enough to use.

I am not just interested in producing good code for one machine, but
good code in general, and I believe that this can be done without
requiring every mathematician or physicist wanting good procedures
for non-uniform random numbers to learn Lisp.

>So as near as I can see, solutions to the problems Herman Rubin
>complains about are out there, and available for use now.  Herman Rubin
>simply refuses to use them until they are customized for his needs to
>an uneconomical extent.

For an individual machine, they have always been there.  Programming in
obfuscated assembler languages can do anything.

>The bottom line: Herman Rubin is attributing to malice and stupidity
>what is adequately explained by simple economics.

I have generally charged inadvertence rather than malice.  However, I do
charge anyone who leaves out something "because it can be misused" with
malice.  I do charge anyone who says that "these tools are adequate to do
a good quick job" with malice if it is not the case.

The situation is similar to what has happened to our educational system;
we have set up procedures so that more harm than good has been done.  In
education, teaching rote without understanding destroys minds and makes
it difficult to acquire the understanding later; in hardware and software,
restricting the possibilities makes subsequent flexibility much harder.

>: So if C doesn't know how to do a fp divide with integer quotient and a
>: remainder in one instruction, or how to do a "add in parallel, but
>: only on those processors in this mask" (a CM),
>: then no amount of higher-level rewriting will help.

>Yes, this is the most central problem, which Jim Giles mentioned also.
>Some method is needed which will specify the generated code, and yet
>will fit in with the optimizations and register allocations and so on
>which are already in place.  Jim says this "isn't too difficult", but
>I think it is the single most difficult part.  I've seen several
>solutions, each with some advantages over the others.

THIS is one aspect of the problem; the attempt to get a detailed complete
package, instead of putting partial solutions together; the attempt to
take the programmer out of an interactive optimization procedure with the
compiler; the failure to realize that the present so-called optimizations
and register allocations are often bad; etc.

>But ultimately, when you are going after that last 1% or .1% of speed,
>you will simply have to spell out the istream, operation by operation.
>No amounts of hints to the optimizer will ever be enough, because
>ultimately the optimizer can only deal with hints it is prepared to
>accept, and if a programmer comes up with something unforseen by the
>optimizer, there's no simple way to give a hint about it.

So put in simple ways to give hints, instead of saying that no hints
can be given.  The difference is not the last 1% of speed, but often
50% of the running time or more.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)