Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why unix doesn't catch on
Summary: Compilers better than programmers...
Message-ID: <932@aber-cs.UUCP>
Date: 11 May 89 14:56:46 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Followup-To: comp.arch
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 51

In article <30789@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes:

    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".

Agreed... One of major reasons that have always been given for using HLLs is
that a code generator written by an excellent (like those that should do
code generators) programmer tipically will be better in speed and reliability
than that done by a average (like most application ones) programmer in
assembler.
    
    |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.

Let me add one story... The Burroughs mainframes have a very compact, high
level (but RISCy) instruction set, designed for Algol. No assembler program
was meant to be ever written for that machine. Unfortunately, the very first
Algol compiler *had* to be written (for bootstrapping) in assembler, and so
it was.  Eventually, it was (reluctantly) recoded in Algol, and it turned
out that it was faster and smaller. And this on a machine with a relatively
high level machine language...  Ah, by the way, this story is dated late
fifties -- early sixties... :-) :-(.  [note: I don't remember where I read
this, but probably in Organick's book.]
    
    [This probably isn't the right forum to discuss these things in....]

Followups redirected to comp.arch.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk