> Let's just say, the CPU is doomed. So you're building consensus for something that is doomed?
> > Seriously thought I don't really understand what sort of response > > you're expecting. > > Just consensus building. To build a consensus you have to have something for people to agree or disagree with. > > Do you have any justification for aiming for 8x parallelism in this > > release and 2x increase in parallelism in the next release? > > Our standard box we ship today that people do compiles on tends to be > a 4 way box. If a released compiler made use of the hardware we ship > today, it would need to be 4 way. For us to have had the feature in > the compiler we ship with those systems, the feature would have had > to be in gcc-4.0. Intel has already announced 4 core chips that are > pin compatible with the 2 core chips. Their ship date is in 3 days. > People have already dropped them in our boxes and they have 8 way > machines, today. For them to make use of those cores, today, gcc-4.0 > would had to have been 8 way capable. The rate of increase in cores > is 2x every 18 months. gcc releases are about one every 12-18 > months. By the time I deploy gcc-4.2, I could use 8 way, by the time > I stop using gcc-4.2, I could make use of 16-32 cores I suspect. :-( > > > Why not just aim for 16x in the first instance? > > If 16x is more work than 8x, then I can't yet pony up the work > required for 16x myself. If cheap enough, I'll design a system where > it is just N-way. Won't know til I start doing code. 4.2 is already frozen for release, and the feature list for 4.3 is pretty much fixed at this point. I wouldn't expect any work of this scale to be released before gcc4.4. By your own numbers this means you should be aiming for 32x. > > You mention that "competition is already starting to make > > progress". Have they found it to be as easy as you imply? > > I didn't ask if they found it easy or not. Do you have any evidence the scheme you're proposing is even feasible? > > whole-program optimisation and SMP machines have been around for a > > fair while now, so I'm guessing not. > > I don't know of anything that is particularly hard about it, but, if > you know of bits that are hard, or have pointer to such, I'd be > interested in it. You imply you're considering backporting this to 4.2. I'd be amazed if that was worthwhile. I'd expect changes to be required in pretty much the whole compiler. Your strategy is built around the assumption that the majority of the work can be split into multiple independent chunks of work. There are several fairly obvious places where that is hard. eg. the frontend probably needs to process the whole file in series because previous declarations effect later code. And inter-procedural optimisations (eg. inlining) don't lend themselves to splitting on function boundaries. For other optimisations I'm not convinced there's an easy win compared with make -j. You have to make sure those passes don't have any global state, and as other people have pointed out garbage collection gets messy. The compile server project did something similar, and that seems to have died. If you're suggesting it's possible to make minor changes to gcc, and hide all the threading bits in a "manager" module then simply I don't believe you. Come back when you have a working prototype. I don't know how much of the memory allocated is global readonly data (ie. suitable for sharing between threads). I wouldn't be surprised if it's a relatively small fraction. If you have answers for the above questions, or some sort of feasibility study, maybe you could publish them? That would give people something to build a consensus on. So far you've given a suggestion of how we might like it to work but no indication of feasibility, level of effort, or where problems are likely to occur. Paul
