[fpc-devel] Compiler trheads (was: NoGlobals branch)

Hans-Peter Diettrich DrDiettrich1 at aol.com
Thu Aug 12 17:08:55 CEST 2010

Helmut Hartl schrieb:

> After doing years of multithreaded development in our communication 
> appliance
> we found that apple came to a similar solution like our own, and took 
> the time to write it down :-)
> http://developer.apple.com/mac/library/documentation/General/Conceptual/ConcurrencyProgrammingGuide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW1 

Nice :-)

But another idea came just into mind, something like PERT/GANTT 
diagrams, used to optimize production plants. What if we instrument the 
current code with time measurement for all tasks, that can be 
parallelized in future? Then somebody could write an analytic program 
for the tasks and their measured times, so that we can learn more about 
the real chances and possible wins...

   A uses B,C;
   B uses D,E;
   C uses D,F;
we get the sequential flow, using e.g. A1/2 for the 
interface(1)/implementation(2) processing:
   A1 B,                         C;                   A2
         B1 D,       E;       B2    C1 D, F;       C2
               D1 D2    E1 E2          <-    F1 F2
or flat
   A1 B, B1 D, D1 D2 E; E1 E2 C; C1 D, F; F1 F2 C2 A2
that could be parallized into
   A1 B, B1 D, D1 E; E1 C; C1 D, F; F1
                 +D2   +E2+B2         +F2+C2+A2

Here we can see that massive parallelism occurs at the end of the 
compilation, so that the determination of the shortest pathes (to the 
first compilable unit) may be the key to best performance, whereas a 
restriction of the number of parallel threads may result in performance 
degradation. But we will know more only after an analysis of real-life 
projects, and with real times for the parallel parts.


More information about the fpc-devel mailing list