Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.misc
Subject: Re: Another 1.3 wish.
Message-ID: <4564@jade.BERKELEY.EDU>
Date: Mon, 3-Aug-87 21:51:54 EDT
Article-I.D.: jade.4564
Posted: Mon Aug  3 21:51:54 1987
Date-Received: Thu, 6-Aug-87 00:42:43 EDT
References: <8707190424.AA10158@cogsci.berkeley.edu> <434@sugar.UUCP> <3664@well.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 69

In article <3664@well.UUCP> ewhac@well.UUCP (Leo (My glasses have gate arrays) Schwab) writes:
<Compilers can do a good job, but never as good as a human.

That's what you get for dealing with shoddy compilers - which most C
compilers qualify as. A good compiler will optimize thing to a degree
that most humans can't match. A good example is that VMS C (one of the
exceptions to the above; I'm not meaning to slight anyone, it's just
the one I'm familiar with) takes something like:

main() {
	register int	a, b ;
	a = 6 ;
	b = 8 ;
	printf("%d", a + b) ;
	}

and turns it into:

	push	14			; I'm not using real VAX mnemonics...
	push	<address of "%d">	; so that those not exposed to
	jump	printf			; such see what's going on.

Sure, on 8080 and similar (eighty-eighty sux family, maybe?) where
stack operations are expensive, useing a compiler - no matter how good
- usually looses to even a moderately good human. But on modern
architectures, where the difference between a stack access and a
global access is small, it doesn't matter as much. On these, the
compiler knowing some non-obvious sequences can make up for that.

<	I'm not knocking high-level languages.  I use them a lot, and would
<be very lost without them.  In fact, if you know how a particular compiler
<behaves, you can get some very efficient code out of it.  But it should be
<agreed that assembly has its place in the world, and should not be
<arbitrarily poo-poohed.

Yes, and that place is in doing things that your high-level language
isn't capable of. And - in time-critical pieces of code - in squeezing
the last microsecond out. But for other things, it just isn't worth
it.

In most cases, there are *better* ways to improve code if it's in a
high level language than by mapping the algorithm to assembler. Two
examples follow:

Once upon a time, a group wrote a microcode compiler for their
machine. They then rewrote the microcode in their new high level
language. The next step was to rewrite some of the code to use better
algorithms (now that they understood it). Result: the high-level
version was 75% of the size and run in 66% of the time of the original
assembler version.

A second time, someone had an application that was spending a *lot* of
it's time in the math library. Like 90+%. Mostly doing sin() and
cos() calls. The "rewrite it in assembler" school would have led to a
few weeks of work tweaking those routines for 10 or 20% more speed.
Not bad, considering how long this thing took to run. However, the
code was getting the same values over and over again, so writing a new
version of sin and cos that cached values from calls to the real thing
and returned them resulted in a greater than 50% reduction in runtime.
After which, the 10 or 20% from the assembler tweaking wasn't worth
the two weeks it would have taken.

	<mike

--
How many times do you have to fall			Mike Meyer
While people stand there gawking?			mwm@berkeley.edu
How many times do you have to fall			ucbvax!mwm
Before you end up walking?				mwm@ucbjade.BITNET