Re: Folk Theorem: Assemblers are superior to Compilers

steven.parker@acadiau.ca (Steven E. Parker)
Tue, 2 Nov 1993 15:38:18 GMT

          From comp.compilers

Related articles
[21 earlier articles]
Re: Folk Theorem: Assemblers are superior to Compilers rfg@netcom.com (1993-10-30)
Re: Folk Theorem: Assemblers are superior to Compilers qualtrak@netcom.com (1993-10-30)
Re: Folk Theorem: Assemblers are superior to Compilers johnson@cs.uiuc.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers henry@zoo.toronto.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers drraymon@watdragon.uwaterloo.ca (1993-11-01)
Re: Folk Theorem: Assemblers are superior to Compilers dmr@alice.att.com (1993-11-02)
Re: Folk Theorem: Assemblers are superior to Compilers steven.parker@acadiau.ca (1993-11-02)
Re: Folk Theorem: Assemblers are superior to Compilers pardo@cs.washington.edu (1993-11-03)
Re: Folk Theorem: Assemblers are superior to Compilers kanze@us-es.sel.de (James Kanze) (1993-11-03)
Re: Folk Theorem: Assemblers are superior to Compilers vthrc@mailbox.uq.oz.au (Danny Thomas) (1993-11-05)
Re: Folk Theorem: Assemblers are superior to Compilers lenngray@netcom.com (1993-11-07)
Re: Folk Theorem: Assemblers are superior to Compilers rfg@netcom.com (1993-11-13)
Re: Folk Theorem: Assemblers are superior to Compilers synaptx!thymus!daveg@uunet.UU.NET (Dave Gillespie) (1993-11-15)
| List of all articles for this month |

Newsgroups: comp.compilers
From: steven.parker@acadiau.ca (Steven E. Parker)
Keywords: optimize, performance
Organization: Acadia University
References: 93-10-114 93-10-149
Date: Tue, 2 Nov 1993 15:38:18 GMT

rfg@netcom.com (Ronald F. Guilmette) writes:


>I have some vague hope that (when it comes to compilers) we may perhaps
>not be getting the absolute best code generation we can for the simple
>reason that responsible compiler vendors are doing their level best to
>work on the *correctness* of their compilers first, and placing a somewhat
>lower priority of all of the whiz-bang optimizations that we all know and
>love.


Actually what happens in practice is that optimizer people tend to do both
"at the same time". What I have experienced is the following:


    1. An idea is generated for an optimization.
                NOTE: the word generated in this context implies original work done
   by the optimizing team OR work published in the literature of
the area.


    2. After cost/time/benefit analysis has shown the optimization to be
            worthy, proceed to step 3 otherwise dump the idea and repeat the
            process.


    3. Design/implement the optimization. *Always* take correctness into
            account!


    4. Test, test and then test the compiler. Do performance runs to
            determine the "goodness" of the optimization, both on its own and in
            the broader context of the entire compiler.


    5. Depending on the results of step 4 either:
a) Place it into the code base for the next ship.
b) Throw it away.
c) Go back to step 3 to try and get it right.




This process is of course slightly simplified, but in general it does
reflect reality (at least in my experience :-)).


So you see, correctness and performance are very much linked in the
process of creating a "new" optimization. The obvious question then is
"Why aren't all compilers whiz-bang?" Of course there are many reasons for
this. I'll mention some, I'm sure there are many others.


    - Financial
    - Not all people have the same skills
    - Time constraints
    - Business pressures
    - ...


Regards,


-- Steven Parker. (steven.parker@acadiau.ca)
--


Post a followup to this message

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