This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Threading the compiler


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]