Speeding up compilation time for Fortran project

[Kashif__Muhammad]

Hi,

How can I improve/speed-up compilation time of Fortran projects.

I have multiple Fortran projects and the total compilation time is around 20 minutes (only for Fortran project). I'm looking for ways that can help me in improving the overall time of these projects.

Thanks,

[andrew_4619]

You don't give much information. Do you have many source files, or a few monster files? Monster files can slow things down.

VS only build what needs to be built so if you have lots of dependencies then lots need to be built. Use lots of modules causes build cascades, consider more use of submodules.

"Unloading" (deactivating) all the projects in the solution except the one you are working on can also be helpful

[jimdempseyatthecove]

Does the Debug build take 20 minutes? If the issue is with Release build only, then multi-file inter procedural optimizations may be cause for excessive compilation times. This can be mitigated to some extent by examining "monster file size" issues as Andrew suggest and/or assuring that Release build only rebuilds as little as necessary (IOW suffer 20 minute build once, then 30 second builds later).

If IPO is an issue, you can set it to single file IPO or use no IPO during development (then use IPO later when you reach beta test level).

Jim Dempsey

[TimP]

If Jim 's suggestions aren't sufficient you may consider also -Qip- and possibly -O1.

[Kashif__Muhammad]

Thanks for the replies,

to add more details, we've more than 3000 Fortran files in different projects. Some of them are big (>150KB).

The time is more or less same for both debug and release, and no we are not using any kind of IPO. 

optimizing Debug compilation time is important for the time, to save the developer's time

[andrew_4619]

If you have 3000 files and 20 minutes that is an average of 0.4s per file which is quite fast really! But when developing you rarely have to do a full build  only the changed files and any dependants. Is it that you have a large amount of interdependencies such that if you change a couple of files you often build a significant proportion of the project? If that is the case you need to look at reducing interdependencies by restructuring the project if possible.

[jimdempseyatthecove]

Andrew is quite right regarding reducing interdependencies by restructuring the project if possible.

Past experience with a relative small (13 projects 750 sources) yielded approximately 20-fold reduction in build time by restructuring some of the files and projects. In particular, for contained subroutines and functions in modules (that are being revised), consider placing the contained routines outside of the module file and instead define an interface within the module. Doing so, will permit you to make changes to the subroutines and functions without causing a cascade of rebuilds.

BTW it is unfortunate that the Fortran standards committee forbids USE of an interface module inside the subroutine/function who's interface references (you would want to do this to assert interfaces match).

Jim Dempsey

[FortranFan]

jimdempseyatthecove wrote:

..In particular, for contained subroutines and functions in modules (that are being revised), consider placing the contained routines outside of the module file and instead define an interface within the module. Doing so, will permit you to make changes to the subroutines and functions without causing a cascade of rebuilds.

BTW it is unfortunate that the Fortran standards committee forbids USE of an interface module inside the subroutine/function who's interface references (you would want to do this to assert interfaces match).  .

Apart from any pending bugs in Intel Fortran, SUBMODULEs will be a better way to structure the program to prevent compilation cascades.

https://software.intel.com/en-us/fortran-compiler-18.0-developer-guide-and-reference-submodule

https://software.intel.com/en-us/blogs/2015/07/07/doctor-fortran-in-we-all-live-in-a-yellow-submodule

The use of SUBMODULEs along with judicious restructuring of the program to make use of static and/or dynamic-link libraries, one can gain further control as well as "optimization" of compilation time:

https://software.intel.com/en-us/fortran-compiler-18.0-developer-guide-and-reference-libraries

Jim,

With the "MODULE SUBROUTINE" or "MODULE FUNCTION" facility available in a procedure implementation in a SUBMODULE, the Fortran standards committee has effectively introduced the "assert interfaces match" option you seek.

[jimdempseyatthecove]

FF,

If you look at the example provided by the first link, 

1) It is unfortunate that the example did not illustrate how/that "part 1", "part 2", "part 3", "part 4",  and "part 5" can be in separate files.

2) An assumption is that this (separate files) is possible provided that an appropriate USE partentModule is incorporated. However, from the second link provided by Steve Lionel, it illustrates how you go about doing this. Apparently "submodule (colors) yellow" implicitly performs a "USE colors". IOW (IMHO) it becomes an equivalent extension of how one violates prior USE rules. It may have been just as easy to have permitted:

module FOO
USE moduleContainingInterfaceFOO

I agree with you that the use of submodules is the way to go (though I think it was unnecessary to create a new keyword).

BTW the Solution I referenced predated submodule (IVF V8.nn). The technique still works without  "assert interfaces match".

Jim Dempsey