Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why unix doesn't catch on
Message-ID: <30789@bu-cs.BU.EDU>
Date: 7 May 89 20:41:19 GMT
References: <274@tree.UUCP> <635@eecea.eece.ksu.edu> <2333@rpi.edu>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: comp.sys.ibm.pc
Organization: Software Tool & Die
Lines: 34

In article <2333@rpi.edu> fargo@pawl.rpi.edu (Irwin M. Fargo) writes:
|C programs are NEVER going to run faster than Assembler
|programs on the SAME machine.

This is incorrect.  Very good optimizing C compilers have changed
this.  In one recent case, a (good!) programmer using a Silicon
Graphics machine spent a good deal of time writing a speed-critical
section in machine language only to have the C compiler produce code
which was one instruction smaller and ran faster.  He's since given up
trying to out-do the compiler.  Never say "never".

|I can
|envision a day (a day quite some time away) when a compiler will be able to
|create compiled code that runs only marginally slower than the same Assembler
|program.  If anything, I feel THAT is something we should shoot for.  If we
|can reach that goal, then the trade-off between portability and speed will
|become almost unnecessary.

While it is not the case for every architecture, that day has already
arrived for several and in some cases the compilers are better than
the programmers, producing faster code than the best efforts of
assembly programmers.  This shouldn't be surprising; how many people
can actually figure out optimal register allocation beyond a few
hundred lines of code?  A few thousand?  Few to none, I would expect,
and that is just one optimization technique.  Add to this the fact
that higher-level languages tend to be easier to debug than assembler
(about the same number of errors per line of code versus per CPU
instruction, quite a difference most of the time) and you see that
coding in assembler isn't very practical.

[This probably isn't the right forum to discuss these things in....]

jim frost
madd@bu-it.bu.edu