[petsc-dev] Bash tool for handling switching between multiple PETSc branches and configures

[Smith, Barry F.]

> On Jan 6, 2020, at 11:36 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> 
>>  I think they just have the wrong algorithms in their compilers for
>>  modules, I don't think there is anything fundamental to the language
>>  etc that requires that portion of the build to be so slow. 
> 
> Yeah, I think there just hasn't been enough attention to compilation
> performance.  But the dependencies don't help.

  They are inherent.
> 
>>  Also gmake doesn't do a good job of making it easy to get overlap
>>  between building the Fortran modules and compiling the C; in some
>>  experiments I could get some overlap and better times but it was
>>  cumbersome so I gave up.
> 
> Hmm, I usually see FC lines starting early in my build output, but they
> need to be built in sequence so it amounts to a very long pole.

   I did some experimenting a long time ago and it seems on my machine the FC is a pig, if it runs at the same time as C compilers the total time is much higher than running all the FC followed by all the C; since the FC is not parallel I had no explanation for this behavior. Even playing around with different j I couldn't get the FC + C at the same time near the speed of them separately.
> 
> If we can reduce the problem of slow compilation to something a compiler
> author can work on, we should file a bug report.

  Both Intel and GNU have the same issue. I suppose one could construct an artificial set of modules to demonstrate the problem but just search the web everyone complains about it.

  Anyways, aside from the fact that the Fortran source is still generated in the C code repository (not in PETSC_ARCH as it should be). Long Fortran compilers are no longer a problem for me. With my bash script even with the bad location of Fortran source I rarely need to see the Fortran modules recompile.