Threading the compiler

Mike Stump mrs@apple.com
Fri Nov 10 20:47:00 GMT 2006


We're going to have to think seriously about threading the compiler.   
Intel predicts 80 cores in the near future (5 years).  http:// 
hardware.slashdot.org/article.pl?sid=06/09/26/1937237&from=rss  To  
use this many cores for a single compile, we have to find ways to  
split the work.  The best way, of course is to have make -j80 do that  
for us, this usually results in excellent efficiencies and an ability  
to use as many cores as there are jobs to run.  However, for the  
edit, compile, debug cycle of development, utilizing many cores is  
harder.

To get compile speed in this type of case, we will need to start  
thinking about segregating data and work out into hunks, today, I  
already have a need for 4-8 hunks.  That puts me 4x to 8x slower than  
I'd like to be.  8x slower, well, just hurts.

The competition is already starting to make progress in this area.

I think it is time to start thinking about it for gcc.

We don't want to spend time in locks or spinning and we don't want to  
liter our code with such things, so, if we form areas that are fairly  
well isolated and independent and then have a manager, manage the  
compilation process we can have just it know about and have to deal  
with such issues.  The rules would be something like, while working  
in a hunk, you'd only have access to data from your own hunk, and  
global shared read only data.

The hope is that we can farm compilation of different functions out  
into different cores.  All global state updates would be fed back to  
the manager and then the manager could farm out the results into  
hunks and so on until done.  I think we can also split out lexing out  
into a hunk.  We can have the lexer give hunks of tokens to the  
manager to feed onto the parser.  We can have the parser feed hunks  
of work to do onto the manager and so on.

How many hunks do we need, well, today I want 8 for 4.2 and 16 for  
mainline, each release, just 2x more.  I'm assuming nice, equal sized  
hunks.  For larger variations in hunk size, I'd need even more hunks.

Or, so that is just an off the cuff proposal to get the discussion  
started.

Thoughts?



More information about the Gcc mailing list