Compile time

[jgr]

Hi!

I am currently working on a Fortran 95 code that takes very long time to compile.

The code stores all data in modules. The hierarchical structure of the code implies that a lot of modules is contained in other modules which again is contained in other modules.

The code takes very long to build expecially when the /O2 option is set (over 1:30 hour, about 5 min without optimizations). What we see is that the files that take very long to build does not contain any computational code, they only contain rutines linking the modules with the computational algorithms (which are present in other files). These rutines take as input a few number of modules. They take out the necessary data items from the module - a kind of module "expansion" - and then and call the computational algorithms whith a full set of arguments in the old fortran fashion.

Our experience is that if we do the module expansion elsewhere, the file compiles much faster, however the input argument list is enormous. Effectively, if not using modules at all, we would probably not have this problem. We have other codes of similar complexity written in Fortran 77 that compiles within a few minutes.

It is not feasible to remove the modules. But is there anything else we can do? I am looking for any small tricks or compiler options to decrease compile time.

We are using version 9.1 of the Intel Fortran compiler. Would version 10 improve on this?

Thanks in advance for any suggestions.
Jesper

[TimP]

In ifort 10, -O1 disables vectorization (like -Qvec- in 9.1). I can't tell from your comments whether you tried these options.

[jimdempseyatthecove]

Jesper,

From my understanding of your application you have a set of interface subroutines (not to be confused with Fortran Interface declarations). These interface subroutines extract the appropriate data from modules and supply either reference or values to other subroutines or functions. And for some reason compiling your interface subroutines along with your application using/O2 is running very slow.

My suggestion is to make your interface subroutines a static library which is not compiled in your main project. Recompile the interface library only when necessary.

Jim Dempsey

[jgr]

Jim,

This is exactly my problem. However, your solution is not directly applicable - the "problem" is the nightly build (or our build manager?!?), and such a library would require to be a part of the nightly build as well, hence still taking a lot of time.

However, inspired by your ideas, we have tried to isolate the routines taking the time, put them in special files, and only require these files to compile with /O1 instead of /O2.

In the preliminary tests we have not been able to spot any time-penalty in the run-times, so this will be our solution for now.

Though, I would still want to know which compile options I miss when going from /O2 to /O1, and especially how, if possible, to set /O2 and instead disable some other compile options and still get fast compile times.

[jimdempseyatthecove]

>> This is exactly my problem. However, your solution is not directly applicable - the "problem" is the nightly build (or our build manager?!?), and such a library would require to be a part of the nightly build as well, hence still taking a lot of time.

If your interface subroutines are dependent on a .MOD file which contain the Fortran INTERFACE declarations .AND. if the interfaces to not change from day to day then there would be no requirement to recompile the interface subroutines.

However, in a development environment things are not always that simple.

Derivative of suggestion:

Classify your interface subroutines into

a) Frozen - will never change
b) Slushy - seldom changes
c) Liquid - expected to change
e) Gasious - New routines without prior history of interface

These will be compiled as seperate libraries only when the dependent-on interfaces change.

My guess is the vast majority of your interface routiens fall in the Frozen category.
You could reduce the compile time by 95% for these problem files.

Also - the person who built the script for your "Build Manager" (you?) likely took the easy way to insure a successful build. That is to specify Build All without regard to if the build for individual itemswas necessary or not.

Considering the time involved in your nightly builds that you consider writing an efficient make file (NMAKE). Make can evoke DEVENV to build projects when necesary as well as call IFORT, LINK and LIB.

----

I have not experienced compile times as bad as your experience. In a solution that has 12 libraries ~450 files I do have a few files that drag along though. These files use FPP (Fortran PreProcessor) and have many macro expansions (virtualy every line has a macro to expand). I do not know why FPP is such a dog on these files, perhaps each expansion flushes and rewindsthe temp file. Fortunately these files do not change much and recompilation is infrequent.

Jim Dempsey