Path: utzoo!attcan!uunet!mailrus!iuvax!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Bloat costs
Summary: Compilers should not be expected to do too much.
Message-ID: <2273@l.cc.purdue.edu>
Date: 29 Jun 90 00:47:57 GMT
References: <1990Jun27.011149.2406@Stardent.COM> <63034@sgi.sgi.com> <9570@celit.fps.com>
Distribution: na
Organization: Purdue University Statistics Department
Lines: 30

In article <9570@celit.fps.com>, ps@fps.com (Patricia Shanahan) writes:
> In article <63034@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes:
> >In article <1990Jun27.011149.2406@Stardent.COM> wright@stardent.Stardent.COM (David Wright @stardent) writes:

			........................

> >But the original posting stated that it was enough to just
> >right clear code because the optimizer will make the most of it.  In general,
> >it wont.  Maybe someday.
> ...
> 
> I certainly agree that there are steps that can be taken to make FFT
> fast that would not be within the state of the art for compilation
> from a simple source, unless your compiler can recognise FFT's, and is
> in the habit of reading the latest papers on how to do them.

When can people in the computer field realize that this will always be the
case?  There is much that a compiler cannot handle well, and this will 
remain the case.  Computers cannot beat a human adept at something as
simple as chess, let alone the ingenuity required to produce efficient
computational procedures.

One could put FFTs in the language, but there are lots of others.  What
about such simple things as overflows and decent multiplication and
division?  There are numerous operations easily implemented in hardware
and expensive in software.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)