[fpc-devel] New less verbose compilation of trunk
nc-gaertnma at netcologne.de
Wed Mar 7 14:24:10 CET 2012
Sven Barth <pascaldragon at googlemail.com> hat am 7. März 2012 um 14:04
> Am 07.03.2012 13:11, schrieb Henry Vermaak:
> > On 07/03/12 12:02, Marco van de Voort wrote:
> >> In our previous episode, Henry Vermaak said:
> >>>>> PS:
> >>>>> Adding any more (if possible) parallel compilation support would be
> >>>>> awesome too. This already saves me over 1 minute in compile time on
> >>>>> quad core. Yes, I hate it if CPU's just sit idle.
> >>>> IIRC add FPMAKEOPT='-T 3' (3= number of paralel threads)
> >>> This makes a big difference for me:
> >>> Without FPCMAKEOPT: 1m48.056s
> >>> With FPCMAKEOPT="-T 9": 1m13.833s
> >>> Unfortunately, cycling the compiler is taking really long and -j 9
> >>> helping much (or at all).
> >> fpmake only handles packages/.
> >> fpmake (or make -j the way FPC used it in the past) can't really speed
> >> runs that are a single compiler invocation (like the compiler), unless
> >> can run two such runs in paralel.
> >> In packages this is possible, in the compiler cycle compiler depends
> >> on RTL,
> >> and the "next" rtl depends on the "previous" compiler, so nothing can
> >> done there.
> >> To exploit paralellism in single compiler invocations, threading
> >> should be
> >> brought into the compiler, but that is an huge and uncertain job.
> > With c, the compilation of .c -> .o is isolated, so many of them can be
> > run in parallel, which means that compiling e.g. the linux kernel, you
> > get great performance from make -j %d. Is it possible to have fpc do
> > same thing somehow? Bringing threading into the compiler sounds very
> > scary, indeed.
> In C the dependencies between the .o files are resolved at link time
> while in Pascal they are already resolved at compile time (the unit
> concept). So the only feasible possibility for a speed up there is
> threading support in the compiler as only the compiler fully knows the
> dependencies between the units.
Compiling C typically starts many times the compiler. Each time the OS has
to load the compiler, resolve the symbols, load all needed header files,
translate them, ... This is a waste of resources. Of course you can do this
waste easily in parallel.
FPC is clever enough to do most things only once. That's hard to do in
Loading the PPU files takes about 10-50%. This might be doable in parallel.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel