🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11539

Re: Compilers and efficiency

#11539
From: Herman Rubin
Date: Mon, 13 May 1991 20:29
48 lines
2992 bytes
In article <rwa.674151323@aupair.cs.athabascau.ca>, rwa@cs.athabascau.ca (Ross Alexander) writes:
> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
			
			.................

> >To clarify, I meant the specific ability to place the transmission in low gears.
> 
> But the auto transmission knows when to do that for you.  Some poor
> underpaid mechanical engineer spent years designing an analogue
> (fluid) computer that monitors engine speed, accelerator position,
> drive wheel speed, and torques and then selects a gear ratio with a
> view to optomizing fuel economy, engine wear, and ghods know what
> else.

According to those who know, they do not do a very good job.  And there
are situations in which the overrides are needed; why do you think that
the manufacturers still keep them?  There are places I would not drive
without using these overrides.

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

> >Current computer hardware can do anything,assuming sufficient external storage,
> >but not efficiently.  Similarly with software.
> 
> I can only wonder that, if they're inefficient, why are they so much
> faster and cheaper that they used to be?  What the heck do you mean by
> `efficient'?  Obviously some new use of the word I was previously
> unaquainted with (apologies to Arthur Dent).

If you make something 10^6 times as fast, and with 10^5 times the capacity,
and get 10^4 times as much done, it is not as efficient.  Now these are not
precise figures.  But the CRAYs, for example, take about 20 instructions
to perform a double precision multiplication of two single precision
numbers, while the CYBER 205 takes exactly 2.  The earliest computers
multiplied two integers of more than 32 bits and obtained a double length
result in one instruction.  I suggest you program this on your box, and
see how many instructions it takes, if the instruction is not there.

If some hardware does not have communication between the integer and floating
registers, conversion is a real horror.  I do not think that any kludge is
likely to be as bad as the complicated code needed, using memory, no less.
Now the early computers were fast on memory and transfer, but the newer
ones are very definitely not so, unless trickery is used.

-- 
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)
Technical Details
Message-ID: <12268@mentor.cc.purdue.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
References: <9782@mentor.cc.purdue.edu> <653@ctycal.UUCP> <28297C23.6984@tct.com> <rwa.674151323@aupair.cs.athabascau.ca>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.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: Compilers and efficiency
Message-ID: <12268@mentor.cc.purdue.edu>
Date: 13 May 91 20:29:30 GMT
Article-I.D.: mentor.12268
References: <9782@mentor.cc.purdue.edu> <653@ctycal.UUCP> <28297C23.6984@tct.com> <rwa.674151323@aupair.cs.athabascau.ca>
Sender: news@mentor.cc.purdue.edu
Lines: 48