optimizing compiler against iaverage assembly programmer.

gclind01@starbase.spd.louisville.edu (George C. Lindauer)
15 Jun 1997 22:50:14 -0400

          From comp.compilers

Related articles
optimizing compiler against iaverage assembly programmer. gclind01@starbase.spd.louisville.edu (1997-06-15)
Re: optimizing compiler against iaverage assembly programmer. disc@disclink.com (DISC) (1997-06-19)
Re: optimizing compiler against average assembly programmer. cef@geodseic.com (Charles Fiterman) (1997-06-19)
Re: optimizing compiler against iaverage assembly programmer. cliffc@risc.sps.mot.com (Cliff Click) (1997-06-19)
Re: optimizing compiler against iaverage assembly programmer. gmiller@iswt.com (Greg Miller) (1997-06-20)
Re: optimizing compiler against iaverage assembly programmer. lehotsky@tiac.net (1997-06-20)
Re: optimizing compiler against average assembly programmer. tgl@netcom.com (1997-06-20)
[34 later articles]
| List of all articles for this month |
From: gclind01@starbase.spd.louisville.edu (George C. Lindauer)
Newsgroups: comp.compilers,comp.lang.asm.x86
Date: 15 Jun 1997 22:50:14 -0400
Organization: University of Louisville
Keywords: practice

I was thinking about the assertion 'a good optimizing compiler will
nearly always outcode a moderately proficient assembly programmer'.


Clearly, this is true if I do what proponents of this always suggest,
that is compare single procedures as written by an average programmer
and as generated by a compiler.


But I have never seen anyone take it any further than this. I have
several questions:


1) What does the average assembly programmer do with the linkage
between procedures? Does a good compiler still beat this? How does
that affect the proposition?


2) in the real world we have two reasons for the average programmer's
dilemma: a) skill and b) constraints of management that often
emphasize fast turnaround over good engineering? A good optimizing
compiler doesn't change your skill level, it just lets you avoid
dealing with a lot of detail. I would suggest if you can't optimize a
few variables into registers by hand that is going to extend to your
choice of algorithms to use with HLLs... that you are going to be just
as likely to pick ineficient algorithms at this higher level as you
were at the lower level. Neither does a good optimizing compiler get
around constraints of management... if you didn't have time with that
assembler but now you use a compiler so you suddenly have time to
engineer everything using good techniques, well, it just isn't going
to last in the real world. Again, management is eventually going to
push you to use that extra time to develop more code faster.
Everything but the basic 'make sure it works' gets lost in some
environments. Going to a compiler just doesn't make it so you can
suddenly do better engineering in this situation either...


What I am wondering is, has anyone factored these types of things into
where compilers fit in the scheme of things? Are good optimizing
compilers really all they are cracked up to be? Or is it simply true
that academic types like to think their work important and business
types accept it because they can turn out more inefficient code,
faster, and still have things run just barely well enough to satisfy
their customers? (with of course the help of hardware types who make
things so fast that no matter how inefficient we might get they still
work out).


David
[Other important points: compilers make it a lot easier to use complex
data structures, and compilers don't get bored halfway through and generate
reliably pretty good code. -John]




--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.