NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9387

Internet Message Format | 1992-09-13 | 5.4 KB

Xref: sparky comp.arch:9387 comp.lang.misc:3050
Path: sparky!uunet!usc!sdd.hp.com!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!ogicse!orstcs!orstcs!usenetusenet
From: [e-mail] (Lawrence Crowl)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Message-ID: <[e-mail]>
Date: 13 Sep 92 03:36:02 GMT
Article-I.D.: CS.1992Sep13.033602.3708
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Oregon State University, Corvallis Oregon
Lines: 91
Nntp-Posting-Host: jade.cs.orst.edu

In article <[e-mail]>
[e-mail] (Herman Rubin) writes:
>In article <[e-mail]>
[e-mail] (Lawrence Crowl) writes:
>>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.

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.

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

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

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

Are you abandoning your claim that design is cheaper in hardware than software?

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

If you are saying that current packages are poorly implemented and that you
can do better.  Show us.  Write one up and release it to the market.

If you care to argue that computer architects are inadequately supporting an
important (and profitable) application area, then do so.  Show us how design
feature F costs C and gives benefit B.  Don't run around telling everyone that
designs architectures or programming languages that they're stupid.  We're
not.  We just have a more practical assessment of the value of those feature
_to_the_market_as_a_whole_ than you appear to have.

I think that in many ways current computer architecures don't support
arithmetic to the level that is desirable.  One of my students and I are
working on this problem now.  Note however that we are working on the problem
and not moaning on the net.

Posts of the form "here's an idea, what do you think?" are great.  Those are
why this net is useful.  Posts of the form "if I had this architectural
feature, I could do these things this much more efficiently" are wonderful.
An architect may agree and do it.  Posts of the form "you guys are stupid" are
not welcome.

--
  Lawrence Crowl        503-737-2554    Computer Science Department
               [e-mail]    Oregon State University
          ...!hplabs!hp-pcd!orstcs!crowl    Corvallis, Oregon,  97331-3202