Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewar <de...@adacore.com> wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on current
PC's, using just one core).
Heh, you always bring up the Realia compiler when there's a compile
time discussion. Must have been a really impressive piece of work,
that it was so fast :-)
Well if you look at the parameters ... that compiler was written
in the early 80's (the first machine on which we ran it was a
PC-1 with diskettes, and it achieved about 10,000 lines/minute
in that environment. Why was compilation time important? Because
COBOL programmers did and still do routinely write very large
programs (a COBOL program = a C function roughly). A COBOL
run-unit (= a C program roughly) is composed of one or more
programs, and very often it was the style for there to be
only a few really large programs, so even back in 1980, COBOL
programmers routinely compiled files consisting of tens of
thousands of lines of code. So compile time speed was a factor.
And indeed Realia COBOL was much faster than the major
competitor Microfocus.
But the interesting thing is that over time, that advantage
evaporated. It was very interesting to compile 10,000 lines
a minute when the competition does only 1,000 lpm, but it
is no longer so exciting to compile 1,000,000 lpm with the
competition managing 100,000 lpm, since both are fast
enough in practice.
GCC has taken a decision to favor
performance of the code absolutely over compiler performance.
That's not such a bad bet given how fast machines are getting.
So I think this compile time advantage is not that interesting.
I disagree (how unexpected is that? :-).
I think you are right that it is not per se a bad decision to favor
performance of the code over performance of the compiler itself. But a
quick investigation of, say, compile times for a linux kernel from GCC
3.1 to GCC 4.5 shows that GCC slows down faster than what Moore's law
compensates for.
You are ignoring the multi-core effect!
It's interesting to look at the time it takes to run our internal
gnat test suite (tens of millions of lines of code, hundreds
of thousands of files, 12000 distinct test cases).
This used to take about an hour for many many years, the test
suite seemed to grow fast enough to compensate for improved
processor performance.
But with the advent of multi-core machines, the picture has
changed entirely, although the test suite has continued to
grow rapidly in size, the time to run it is now down to
15 minutes when we run on a multi-core machine, and we just
got a machine with 2x6 cores, each hyperthreaded, which will
probably cut this in half again.
Given it is so easy to take advantage of multi-cores when
compiling large projects, the overall effect is definitely
that GCC 4.5 is much faster than GCC 3.1 for handling large
projects with latest hardware.
I do realize that some people are running gcc on very old
machines, that particularly happens say in developing
countries or with students or hobbyists using old cast
off machines. And for those compile time is a problem,
but for out Ada users, many of whom have absolutely giant
programs of millions of lines, compile time speed has not
been an issue (we would know if it was, people would
tell us, they tell us of ANY problems they have).
The one exception is that native compilation on VMS
is slow, but that's a consequence of the VMS file
system, where opening lots of small files is slow.
We are planning to encourage people using VMS to
switch to using PC-based cross-compilation.
