|[15 earlier articles]|
|Re: Speedy compilers Rudi.Ziegaus@bingo.baynet.de (1998-12-18)|
|Re: Speedy compilers email@example.com (Jeff Jackson) (1998-12-18)|
|Re: Speedy compilers firstname.lastname@example.org (1998-12-19)|
|Re: Speedy compilers email@example.com (1998-12-19)|
|Re: Speedy compilers firstname.lastname@example.org (1998-12-19)|
|Re: Speedy compilers email@example.com.OZ.AU (1998-12-19)|
|Re: Speedy compilers firstname.lastname@example.org (1998-12-19)|
|Re: Speedy compilers email@example.com (1998-12-19)|
|From:||firstname.lastname@example.org (Richard Weaver)|
|Date:||19 Dec 1998 11:23:42 -0500|
|References:||98-11-047 98-11-086 98-11-089 98-12-040|
Rudi.Ziegaus@bingo.baynet.de (Rudi Ziegaus) writes:
>[ re how much people care about compile speed vs. runtime speed ]
>There is a golden rule to code optimization, that I like to cite :
>"Never use it". [snip]...
Sorry, but your golden rule is not an option that you have.
Just generating in-line code is an optimization; we used to generate
And generating subroutine calls, when we did that, was an
optimization; we used to generate pseudo code to drive an interpreter
(and for some languages we still do for things like format lists).
And doing our own assembly was an optimization; we used to cascade to a
separate assembler product.
And dead code elimination, and common-expressions, and ...
For HLLs you are stuck with optimizations, lots of them. There are
only a few optimizations where their resource requirements are such
that you have control over their use.
[I think the message here is that compilers that work are preferable to
compilers that don't. -John]
Return to the
Search the comp.compilers archives again.