Compilation times

[dajum]

HI,

I have a source, it is about 92000 lines of code with about 1000 routines in it. It takes about 20-25 mintues to compile in IVF 9.1 and 10.1. In CVF, DVF or Lahey the same source takes about 1 minute. Is there some option set which is causing this? Or one that will speed it up?

my flags are:

astap.for /fpe:0 /names:lowercase /Oy- /iface:cref /module:"c:v51ivfprocesproces___Win32_Release" /MT /libs:dll /iface:mixed_str_len_arg /include:c:v51ivfprocesproces___Win32_Release /nologo /assume:byterecl /extend_source:132 /O3 /list /traceback /link /OUT:"astap.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"msvcrt.lib" /SUBSYSTEM:CONSOLE c:v51ivfprocesproces.lib c:v51ivfutilutility.lib c:v51ivfprocesisight.lib c:v51ivfproces dsubproc.lib statwin.lib
c:v51ivfprocessfmatlab.lib c:v51IVFutilutility.lib /MAP /F:6000000

Thanks

Dave

[TimP]

Among the time-consuming compile phases present in ifort but not in those other compilers are interprocedural and auto-vectorizing optimizations. ifort 10.1 turns off vectorization at -O1. I hate to offer advice on those cryptic Microsoft style options; maybe -Ob- -GL- will turn off inter-procedural? Obviously, no one can say from your minimal description where the time is spent.

[dajum]

Are you suggesting /Ob1 or /Ob0 ? I can't find a description for GL so I have no idea what you mean there. You seem to be implying that I'm not using Intel compiler flags, can you suggest better flags to turn on optimixation than /O3?

Dave

[Steven_L_Intel1]

I have seen issues in the past when a source had many, many routines and it took a long time to compile in ifort. If you split the source into smaller pieces, does the total time go down? Does this source have initialization of large arrays?

Try compiling with optimization disabled and see if the time changes significantly. That will at least tell you if optimization or something else is to blame.

[dajum]

It isn't an optimization problem. /Od doesn't affect it much (still 13 minutes). Took out most of the other switches as well. THe source is built programatically and we aren't really set up to generate multiple sources to compile so it isn't a good solution for us. But I tried splitting the file in half. Total time was then 5 minutes versus the 13. So there must be some sort of nasty linear searching, or multiple reads from the source going on in the compiler.

Does that help you help me more?

Dave

[Steven_L_Intel1]

At this point I would ask that you submit an issue to Intel Compiler Support, attach this source (and any sources it depends on), describe the problem and note that you were referred from the forum. My guess is that it's a code generator issue which I have seen with sources containing hundreds of small routines.

[TimP]

You're correct, it's not practical in Windows build environment to use scripts which split the source automatically (using fsplit, f90split, or the like) and then use relocatable link to combine multiple .obj. This common HPUX practice is followed frequently in linux as well.

The compiler builds several tables which expand with multiple subroutines in the source, even at /Ob0. This can be a big factor in compilation time if memory is short (giving an advantage to X64).

[Steven_L_Intel1]

tim18:

This can be a big factor in compilation time if memory is short (giving an advantage to X64).

Well, it's not an advantage for compiling - yet. Our x64 compiler is actually a 32-bit application. But a native x64 compiler is coming in the next major release.

[DavidWhite]

Steve,

Ever since I changed from CVF to IVF several years ago, I have been unimpressed with the compile times of IVF vs CVF. My major project is split into 200 separate source files, so having separate files or having a single source file does not make any difference. IVF simply compiles slower than CVF. In my experience it takes about two to three times as long.

David

[Steven_L_Intel1]

I've certainly seen cases like that, and others where the speeds were comparable. The Intel optimizer and code generator is a different design than that of CVF and it is slower in some cases. The Intel optimizer is doing more work and (almost always) getting better results.

If you find a case where the compile speed is much slower, please submit a test case to Intel support so that it can be analyzed. We've made good progress speeding up some compilations in the past.

[Kevin_D_Intel]

The Fortran Front-end developer who worked this issue Dave reported identified the long compilation time in his case relates to the large number of routines and large number of common block declarations, and the IVF algorithm related to detecting duplicate common block declarations. The developer addressed the long compile time by speeding up the algorithm to detect name conflicts between common blocks and routines and filtering out duplicate common block declarations (in different routines) earlier.

We are targeting these changes to our next major release.

Thank you Dave for the nice reproducing test case. To quote the Developer:

Thanks for providing the complete source -- it made it much easier to identify the problem quickly.