Path: utzoo!utgpu!watmath!att!bellcore!rutgers!cs.utexas.edu!uunet!bfmny0!tneff
From: tneff@bfmny0.UUCP (Tom Neff)
Newsgroups: comp.lang.c
Subject: Re: C vs. FORTRAN
Message-ID: <14526@bfmny0.UUCP>
Date: 8 Aug 89 16:38:29 GMT
References: <3288@ohstpy.mps.ohio-state.edu> <225800204@uxe.cso.uiuc.edu> <14523@bfmny0.UUCP> <24633@prls.UUCP>
Reply-To: tneff@bfmny0.UUCP (Tom Neff)
Organization: ^
Lines: 22

There are always projects floating around that DO require squeezing the
last cycle out of a module, and I've worked my share of them; but there
is a preponderance of projects where this kind of cycle squeezing is a
waste of the company's money.  The trick is knowing how to tell the
difference, and I find that many programmers don't.  

For every exceptional story where someone had to shave a DECX
instruction to keep the Exxon Valdez autopilot in synch, there are 10
real life stories within a block of me where people are rewriting
once-a-day startup modules in assembler because they think it's cool to
"use tighter code."  Or a hacker consultant sitting at his desk pounding
out incomprehensible spaghetti code and greeting puzzled inquiries with
that withering look and the cry, "Listen sucker THIS has to run FAST!"
... followed by the inevitable sequel scene three years later when I'M
still there and the COMPANY'S still there and this MODULE'S still there
-- dead in the water -- but the consultant is now a rafting instructor
in Utah somewhere and Joe Tyro is tasked with fixing the code.

Knowing WHEN to optimize is as important as knowing HOW.
-- 
"We walked on the moon --	((	Tom Neff
	you be polite"		 )) 	tneff@bfmny0.UU.NET