Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <5877@mentor.cc.purdue.edu>
Date: 14 Feb 91 17:41:30 GMT
References: <3159:Feb1213:56:3091@kramden.acf.nyu.edu> <1991Feb12.192725.21029@Think.COM>
Sender: news@mentor.cc.purdue.edu
Lines: 50

In article <1991Feb12.192725.21029@Think.COM>, barmar@think.com (Barry Margolin) writes:
> In article <3159:Feb1213:56:3091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Some people think that if Fortran and C don't support an operation, it's
> >a waste to put the operation into new chips. They're wrong. Just because
> >language designers make mistakes doesn't mean those mistakes should last
> >forever.
> 
> My guess (based on no hard evidence) is that Fortran and C are used for at
> least 75% of systems and scientific programming, and this will almost
> certainly be true for the lifetime of the coming generation of processors.
> In this case, it makes sense for chips to be designed with those languages
> in mind, since they aren't going away soon no matter how many mistakes the
> language designers made (technical superiority hardly ever wins in this
> business -- consider how many systems running IBM's horrible mainframe OSes
> there are).  Yes, that means that the small minority of programs that can
> make use of other operations will not be optimized as well.  But if 50% of
> all programs double in speed while 10% are halved in speed (I think I'm
> exxagerating the numbers in both directions), and the rest stay about the
> same, and CPU prices also go down, that's a large overall gain.

Even this is misleading.  Although unfortunately it is not completely true,
to a considerable extent the libraries are produced by people with a better
understanding of programming.  The missing instructions are useful in such
things as computing the elementary transcendental functions, or in doing
mixed integer and floating point arithmetic, supported by both of the major
languages above and most others.  Even if a separate arithmetic unit for
doing the good arithmetic is needed, non-business users are likely to be
willing to pay for it.

I doubt that incorporating a larger instruction set need have much effect
in slowing down the existing programs.  The hardware for good integer 
arithmetic and for floating point arithmetic is essentially the same,
with some complications for the floating point part.  Possibly the larger
instruction set would slow things down on the order of 5%.  I suggest that
those who think that not much slowdown occurs in these other problems try
programming them.

Some of the new "hot" hardware does not even support efficient conversion
between integer and floating point.  On the RS/6000, this is a real beast,
involving several instructions and using memory for the transfer.  The time
factor for this is likely to be around 1/10 rather than 1/2.  If multiple
precision arithmetic is needed, the factor is likely to be at least as large,
and the programs using it are mainly using it.  So it is more 50% of the
programs running 5% or less slower, 15% taking several times as long to 
run, and the rest somewhere in between.

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