[fpc-devel] Blackfin support

[Hans-Peter Diettrich]

Marco van de Voort schrieb:
> In our previous episode, Hans-Peter Diettrich said:
>>> For me, a much higher priority when doing rewrites might be
>>> multithreading nf the compiler itself.
>> That's questionable, depending on the real bottlenecks in compiler 
>> operation. I suspect that disk I/O is the narrowest bottleneck, that can 
>> not be widened by parallel processing.
> 
> No that has to be solved by a bigger granularity (compiling more units in
> one go).  That avoids ppu reloading and limits directory searching (there is
> a cache iirc) freeing up more bandwidth for source loading.

ACK. The compiler should process in one go as many units as possible - 
but this is more a matter of the framework (Make, Lazarus...), that 
should pass complete lists of units to the compiler (projects, packages).

As a workaround a dedicated server process could hold the least recently 
processed unit objects in RAM, for use in immediately following 
compilation of other units. But this would only cure the symptoms, not 
the reason for slow compiles :-(


> Not only compiling goes in paralel, I assume one could also load a ppu in
> parallel? (and so parallelize the blocking time of the disk I/O and the
> parsing of the .ppu contents.

It may be a good idea to implement different models, that either read 
entire files or use the current (buffered) access. Depending on disk 
fragmentation it may be faster to read entire (unfragmented) source or 
ppu files, before requests for other files can cause disk seeks and slow 
down continued reading of files from other places. Both models can be 
used concurrently, when an arbitration is possible from certain system 
(load) parameters. In the easy case an adjustable source file buffer 
size (command line argument) would allow to check and optimize file 
processing from outside the compiler, independently from (future) 
internal threading.

DoDi