From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 13 Sep 92 18:08:39 GMT
Organization: Purdue University Statistics Department

In article <1992Sep13.033602.3708@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>In article <BuFK3y.3H5@mentor.cc.purdue.edu>
>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>In article <1992Sep11.184744.19329@CS.ORST.EDU>
>crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:

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

>I've been computing for 17 years, and in all that time I don't think I've
>done characteristic roots more than a couple of times.  My sister has been
>word processing, spread-sheeting, etc. for six years, and I don't think she's
>ever done a characteristic root.  So, 23 years of computing, 2 roots.  You
>could increase the cost of those roots by two orders of magnitude and I
>wouldn't remember or care about the time.  Under these circumstances, the
>designers made the right decision in not making me pay for this hardware.

Who would expect procedures like that to make good use of square roots?
I suspect that if fixed-point arithmetic were used for spreadsheets, it
would be faster than floating.

>>>>Bit vectors do not necessarily start on a word, or even a byte, boundary,
>>
>>>Yes, but if only one in a million don't, supporting non-aligned bit vectors
>>>probably isn't cost effective.

>>"Natural" programming on the CYBER 205 would have at least an appreciable
>>portion of bit vectors unaligned, if not most.  Now there are ways of 
>>reprogramming to avoid some of this, but very definitely not all.  This
>>programming requires more than a knowledge of HLLs.

>Show me an application (or set of applications) in which non-alligned bit
>vectors matter.  Then show me that those applications constitute a significant
>fraction of the computing market.  Then people will listen.

I suggest you try generating non-uniform random numbers.  The fastest
algorithms by far are acceptance-rejection and related ones.

>Incidently, citing architectures that are no longer cost effective only
>weakens your claim.

The CYBER 205 was certainly cost-effective compared to the CRAY 1 if the
programmers had any idea of what they were doing.  The ETA 10, essentially
the same machine speeded up, would have done well if it were not dropped by
a bumbling management.

>>>My experience indicates that the cost to deliver a working solution to
>>>_almost_any_ problem is cheaper in software than hardware.  Consider the
>>>cost of building a working multiplier versus the cost of writing an
>>>iterative adding subroutine.  I invite you to provide _evidence_ that your
>>>claim is true.

>>But the building of the multiplier is done once, and the adding subroutine is
>>run billions of times.  Ask a designer how much more it would cost to put in
>>fixed multiplication with the accuracy of floating at the time it was being
>>built.  Every floating point unit essentially contains a fixed point unit
>>inaccessible to the user.

>Before you were talking about the cost of design.  Now you wish to talk about
>the cost of use.  They are different.  I grant you that someone that does many
>integer multiplies will get better performance, probably even better
>cost-performance out of an integer multiplier.  However, you are not all
>customers.  If you are the only customer that wants that hardware, it'll cost.

I was discussing hardware modifications which are quite cheap compared with the
cost of the hardware in the first place.  If one only looks at the cost of 
hardware design, there should never be multiply or divide in hardware.  The
cost of using the machine certainly counts.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.arch