Re: Fast code vs. fast compile

Darius Blasband <darius@phidani.be>
22 Jan 1997 00:03:31 -0500

          From comp.compilers

Related articles
Beginner's Question... mihai@A-aod.resnet.ucsb.edu (Mihai Christodorescu) (1997-01-16)
Fast code vs. fast compile dennis@netcom.com (1997-01-16)
Re: Fast code vs. fast compile salomon@silver.cs.umanitoba.ca (1997-01-19)
Re: Fast code vs. fast compile darius@phidani.be (Darius Blasband) (1997-01-22)
Re: Fast code vs. fast compile jlilley@empathy.com (John Lilley) (1997-01-22)
Re: Fast code vs. fast compile mwolfe@dat.cse.ogi.edu (1997-01-22)
Re: Fast code vs. fast compile mikey@ontek.com (1997-01-22)
Re: Fast code vs. fast compile conway@cs.mu.oz.au (1997-01-22)
Re: Fast code vs. fast compile darius@phidani.be (Darius Blasband) (1997-01-25)
Re: Fast code vs. fast compile wws@renaissance.cray.com (Walter Spector) (1997-01-25)
[1 later articles]
| List of all articles for this month |

From: Darius Blasband <darius@phidani.be>
Newsgroups: comp.compilers
Date: 22 Jan 1997 00:03:31 -0500
Organization: Phidani Software, Brussels
References: 97-01-122 97-01-137 97-01-159
Keywords: performance, practice

Dennis Yelle <dennis@netcom.com> wrote:
|> As a compiler user, I am (almost) always more concerned about fast
|> code rather than fast compilation.
|> ...
|> [Perhaps you don't work on very large programs. A few years back when I
|> was recompiling a 600,000 line C program on three platforms every night,
|> I would have been extremely pleased to have a faster compiler available
|> than GCC. -John]


Daniel J. Salomon wrote:
> Actually the two speeds, compilation versus execution, are sometimes related.


As far as my own experience is concerned, compilation speed remains
very important, specially in cases where a low-level language such as
C is used as intermediate language in a large compilation context. In
such cases, the amounts of code that must be compiled can go as far as
a 1.000.000 lines (that is approximatively the amount of C code that
is recompiled here every night. It only represents 140.000 lines of
YAFL code, compiled twice, once with full debugging support, once with
full optimization enabled).


On the other hand, I don't think (intuition only, please feel free to
tell me how wrong I can be) that every execution time improvement
improves the compilation time by similar factors. After that very
basic optimizations have been implemented, every additional % to gain
requires its load of sweat and frustration, and the compiler might
perform lengthy analysis for a very little performance improvement, if
any. In some cases, the performance improvement does not apply to the
compiler itself, which is perhaps not a very typical benchmark
program. In some other cases, the compiler might optimize space rather
than speed...


Well, IMO...


Darius
--


Post a followup to this message

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