- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page