[fpc-devel] New less verbose compilation of trunk

[Sven Barth]

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 my
>>>>> 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 isn't
>>> 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 up
>> runs that are a single compiler invocation (like the compiler), unless it
>> 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 be
>> 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 the
> 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.

Regards,
Sven