This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Minor suggestion
- From: Mike Stump <mrs at apple dot com>
- To: Alex Hornby <alex at anvil dot com>
- Cc: Simon de Hartog <simon at dehartog dot nl>, gcc at gcc dot gnu dot org
- Date: Tue, 9 Dec 2003 13:45:43 -0800
- Subject: Re: Minor suggestion
On Tuesday, December 9, 2003, at 06:31 AM, Alex Hornby wrote:
today I was thinking about the gcc compiler. I run a source
distribution (Gentoo Linux), and found out that simultaneous
compilation of multiple packages actually takes longer than compiling
them in sequence, because of scheduling overhead.
Buy a 2-100 processor box, run with make -j2... You'll notice it is
faster.
Then I asked myself: why does gcc not compile multiple source files
in one go, using threads?
Because it would be even slower. Benchmark fgetc and then fgetc_unlock
as used by gzip for an example.
This reduces overhead and is still quicker, mainly because for
example header files only have to be compiled once,
You've just described the compile server. Congratulations. I just did
a hello world benchmark, 91x faster. Note however, that it doesn't use
threads. It just uses an in memory db of past compilations for
eliminating future work. All compile serialize through each server,
and every server is logically independent, except they all share the
same load balancer to distribute load evenly among n processors. By
not having threads, there is no locking required. In time, we may
share the db in a course way between processors.
I realise that this would mean a huge rewrite
Not that bad actually.