From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 13 Sep 92 04:05:03 GMT
Article-I.D.: CS.1992Sep13.040503.4164
Organization: Oregon State University, Corvallis Oregon

In article <JAN.92Sep12155439@pallas.neuroinformatik.ruhr-uni-bochum.de>
jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
>In article <1992Sep11.184744.19329@CS.ORST.EDU> 
>crowl@jade.CS.ORST.EDU (Lawrence Crowl) 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.
>
>Ah yes. And them somebody thought of an algorithm, reducing the complexity
>of some important programme. Unfortunately, because of a few cents' worth
>of cost savings in the hardware design, the implementation is ten to 1000
>times slower than necessary. Sheesh, how cost effective! 

It is very difficult to anticipate alorgithmic discoveries.  Adding hardware
cost to a product "because someone might find it useful someday" will not
endear you to your customer.  In fact, they'll likely buy your competitors
product.  No architect that has to make money can do anything but follow
algorithmic advances.

If you care to propose specific architectural features that can improve
performance of important algorithms, I'm ready to listen.

>Pray tell, how are you, using this philosophy of "it's only rarely used",
>going to avoid ending up with processors which can do nothing but NANDs?
>They're still Trung machines, but I'd rather not use them for my simulations.

Please!  Reduction to the absurd is a debating technique that is insulting.
I'm all for throwing hardware at any problem for which that hardware is cost
effective for the applications for which it is intended.  I'm not making
arguments based on Turing completeness.  Really.

>   >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.
>
>And that _is_ a simplistic comparison. Why should "many if not most" 
>programmes be good enough reason for elimiting a function?

It isn't.  Nor is the existence of one program that can use a function
justification for including it.

>I think Herman is talking about incremental cost effectiveness.

I agree, and for most program runs, the square root provides very little
increased effectiveness.  However, the cost is constant.

>And to give you an example:  When Inmos added an FPU to the transputer, they
>put in a barrel shifter and a 3bit/cycle mutiplier. Taking these as a given,
>they put in the microcode for square root and remainder because that's all it
>cost them: some more microcode. Should they just leave them out just to spite
>their customers?

All it cost them was some more microcode?  Can you please give this to me in
dollar figures?  Never mind, I'll give you some very low estimates. 

  development: 3 days at $100,000. per year is $820
  testing: 3 days at $80,000. per year is $660
  technical writing: 1 day at $60,000. per year is $160
  manual preparation: 1/4 day at $60,000. per year is $40
  manual printing: 1 page at $0.03 * 10,000 manuals is $300
  toll-free hotline questions: 3 days at $60,000. per year is $500
  and more that I haven't gotten to

So, this feature cost them at least $2500, assuming that it didn't require an
increase microinstruction rom, or didn't have any problems in its development,
and that customers rarely need help getting it to work.

That cost is low enough so that as a manager at Inmos, I'd probably make the
same decision.


>   >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 nonaligned bit vectors
>   probably isn't cost effective.
>
>And again, these decisions are limiting what gets done. Why are currently
>proposed cryptoalgorithms using key lengths that are powers of two? Surely,
>one of the reasons is that current hardware isn't able to process bit strings
>that don't fall on 64 ot 128 bit boundaries efficiently.

Is the fact that key lengths are in powers of two a problem?  How much would
non-power-of-two lengths cost with and without hardware support?  The answer
may just be that non-power-of-two lengths will _always_ cost more.  I don't
know.

>   >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.  :)  
>
>Not quite that, but look at IBM's VM/HPO. A large part of the virtual machine
>assists and thus of VM is actually done in microcode, probably individually
>for every model series. Saving 25% or more of your 3090's processing power
>is certainly worth a few man year's microcoding slavery.

Certainly, but is saving 0.01% of a 3090's processing power worth a year of
microcoding slavery?

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
Newsgroups: comp.arch