This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Threading the compiler
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Ian Lance Taylor'" <iant at google dot com>
- Cc: "'GCC Development'" <gcc at gcc dot gnu dot org>
- Date: Tue, 14 Nov 2006 19:13:15 -0000
- Subject: RE: Threading the compiler
On 14 November 2006 18:30, Ian Lance Taylor wrote:
> "Dave Korn" <dave.korn@artimi.com> writes:
>
>>> The main place where threading may make sense, especially
>>> with LTO, is the linker. This is a longer lived task, and
>>> is the last step of compilation, where no other parellel
>>> processes are active. Moreover, linking tends to be I/O
>>> intensive, so a number of threads will likely be blocked
>>> for I/O.
>>
>> I'm not really sure how this would play with SMP (as opposed to
>> threading). I don't see why you think threading could be particularly
>> useful in the linker? It's the pipeline of compiler optimisation passes
>> that looks like an obvious candidate for threading to me.
>
> It's irrelevant to the main discussion here, but in fact there is a
> fair amount of possible threading in the linker proper, quite apart
> from LTO. The linker spends a lot of time reading large files, and
> the I/O wait can be parallelized.
That's not even thread-worthy, that just required bog-standard AIO
techniques. Um, /are/ there suitably portable AIO techniques? I guess the
answer is going to be "Yeah, spawn a posix thread and make an ordinary
synchronous f* io call in there"! Heh.
> And the linker spends a reasonable
> amount of time computing relocations, which can be parallelized such
> that the relocations for each input file are computed independently.
Ooh yes, big win to be had there.
cheers,
DaveK
--
Can't think of a witty .sigline today....