[fpc-devel] Compiler bottlenecks]
DrDiettrich1 at aol.com
Tue Jul 13 14:41:02 CEST 2010
Jonas Maebe schrieb:
>> I suspect that disk I/O is the narrowest bottleneck,
>> that can not be widened by parallel processing.
> Unless you are doing a cold compile, the main bottlenecks in the
> compiler are the memory manager (mostly the allocation of memory,
> freeing is faster), zero-filling new class instances (and partially
> resetting the register allocator) and tobject.initinstance.
Memory management can not normally be parallelized. Also access to the
newly created instances requires to fill the cache, so that IMO fear
that parallel operations in this area will not speed up anything much.
But since more is done in a thread, there may remain tasks that can fill
the gaps in other threads.
Did you already do some performance analysis in the compiler code? I
never did so myself, and don't know how to obtain really meaningful figures.
>> It also requires further research, for e.g. the determination of
>> the optimal number of threads, depending on the currently available
>> resources on a concrete machine.
> We'd just use the same approach as make: allow the user to specify
> the number of parallel operations.
A safe bet :-)
More information about the fpc-devel