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: 11 Sep 92 20:11:57 GMT
Organization: Purdue University Statistics Department

In article <1992Sep11.184744.19329@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>In article <Bu5qD3.GAM@mentor.cc.purdue.edu>
>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>And then the hardware designers, being told that something is useless, drop
>>it from the instruction set?

>You misunderstand what has happened in the industry.  The hardware designers
>were told that something was rarely used, and therefore was not cost
>effective.  As good engineers, they dropped the feature.

>>Designing flexibility in both hardware and software is not that expensive;
>>putting in something left out may be.

>My experience is just the opposite.  Designing flexibility in either hardware
>or software is very expensive.  Given the time to program a simple utility
>with one option versus one with twenty supports this claim.  The time to build
>an shifter of constant shift versus one of variable shift also supports this
>claim.  I invite you to provide _evidence_ in support of your claim.

>I grant you, putting something in later will be expensive.

>>A simple example is that of square root.  The cost of putting in square root
>>on any machine which has "classical" division hardware is essentially zero
>>at the design and construction stage, but an algorithm to do it is otherwise
>>is necessarily slow and costly.

>Only costly when making simplistic comparisons.  If the lack of square root
>hardware increases my run time from 10 seconds to 10.0001 seconds (which is
>probably realistic for many if not most program runs), it is _not_ costly.

If the increase is that small, not even very many divisions are likely to 
be done.  If one is only interested in the characteristic roots and a 
few characteristic vectors, the most commonly used method at this time,
the QR algorithm, would spend most of its time in computing square roots.
At best, it spends a fair amount in that operation.

>>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.

>>and again, it is easier to deal with the problem at hardware design time
>>rather than in software.

>This claim is strongly supported by the wide abundance of hardware-implemented
>compilers and spreadsheet packages.  :-)  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.

>What you meant to say is "its easier for me if the hardware designers gave me
>exactly what I wanted".

It is also easier for the number theorists, signal processing people, and
anyone who does not rely on cheap inefficient packages, which frequently are
so bad that the roundoff, undetected, gives highly erroneous results.
-- 
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)