<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml">
 <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
 </head>
 <body>
  <p style="margin: 0pt;">
   <span>
    <span></span>
   </span>
  </p>
  <p style="margin: 0px; "></p>
  <div style="margin: 5px 0px;">
   <br/>
   Sven Barth <pascaldragon@googlemail.com> hat am 7. März 2012 um 14:04 geschrieben:
   <br/>
   <br/>
   > Am 07.03.2012 13:11, schrieb Henry Vermaak:
   <br/>
   > > On 07/03/12 12:02, Marco van de Voort wrote:
   <br/>
   > >> In our previous episode, Henry Vermaak said:
   <br/>
   > >>>>> PS:
   <br/>
   > >>>>> Adding any more (if possible) parallel compilation support would be
   <br/>
   > >>>>> awesome too. This already saves me over 1 minute in compile time on my
   <br/>
   > >>>>> quad core. Yes, I hate it if CPU's just sit idle.
   <br/>
   > >>>>
   <br/>
   > >>>> IIRC add FPMAKEOPT='-T 3' (3= number of paralel threads)
   <br/>
   > >>>
   <br/>
   > >>> This makes a big difference for me:
   <br/>
   > >>>
   <br/>
   > >>> Without FPCMAKEOPT: 1m48.056s
   <br/>
   > >>> With FPCMAKEOPT="-T 9": 1m13.833s
   <br/>
   > >>>
   <br/>
   > >>> Unfortunately, cycling the compiler is taking really long and -j 9 isn't
   <br/>
   > >>> helping much (or at all).
   <br/>
   > >>
   <br/>
   > >> fpmake only handles packages/.
   <br/>
   > >>
   <br/>
   > >> fpmake (or make -j the way FPC used it in the past) can't really speed up
   <br/>
   > >> runs that are a single compiler invocation (like the compiler), unless it
   <br/>
   > >> can run two such runs in paralel.
   <br/>
   > >>
   <br/>
   > >> In packages this is possible, in the compiler cycle compiler depends
   <br/>
   > >> on RTL,
   <br/>
   > >> and the "next" rtl depends on the "previous" compiler, so nothing can be
   <br/>
   > >> done there.
   <br/>
   > >>
   <br/>
   > >> To exploit paralellism in single compiler invocations, threading
   <br/>
   > >> should be
   <br/>
   > >> brought into the compiler, but that is an huge and uncertain job.
   <br/>
   > >
   <br/>
   > > With c, the compilation of .c -> .o is isolated, so many of them can be
   <br/>
   > > run in parallel, which means that compiling e.g. the linux kernel, you
   <br/>
   > > get great performance from make -j %d. Is it possible to have fpc do the
   <br/>
   > > same thing somehow? Bringing threading into the compiler sounds very
   <br/>
   > > scary, indeed.
   <br/>
   >
   <br/>
   > In C the dependencies between the .o files are resolved at link time
   <br/>
   > while in Pascal they are already resolved at compile time (the unit
   <br/>
   > concept). So the only feasible possibility for a speed up there is
   <br/>
   > threading support in the compiler as only the compiler fully knows the
   <br/>
   > dependencies between the units.
  </div>
  <p style="margin: 0px;"> </p>
  <p style="margin: 0px;">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. </p>
  <p style="margin: 0px;">FPC is clever enough to do most things only once. That's hard to do in parallel.</p>
  <p style="margin: 0px;"> </p>
  <p style="margin: 0px;">Loading the PPU files takes about 10-50%. This might be doable in parallel. </p>
  <p style="margin: 0px;"> </p>
  <p style="margin: 0px;">Mattias</p>
  <p style="margin: 0px;"> </p>
 </body>
</html>