> The competition is already starting to make progress in this area.
>
> 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?

Can you make it run on my graphics card too?

Seriously thought I don't really understand what sort of response you're 
expecting. You've described how an ideal compiler would work, in fact how 
pretty much any parallel system should be designed to work.

Do you have any justification for aiming for 8x parallelism in this release 
and 2x increase in parallelism in the next release? Why not just aim for 16x 
in the first instance? 16-way SMP isn't that rare even today.

You mention that "competition is already starting to make progress". Have they 
found it to be as easy as you imply? whole-program optimisation and SMP 
machines have been around for a fair while now, so I'm guessing not.

I realise this is a very negative reply, and please don't take it personally.
However I don't think there's much to be gained by vague proposals 
saying "Lets make gcc threaded and not do it in a way that sucks". Like with 
LTO, until someone comes up with a concrete proposal and starts hacking on a 
branch It's all just hot air.

Paul

Reply via email to