Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29251 Discussions

Slow compile times with nested data types

jpapp
Beginner
902 Views
Hello,

I'm currently using IFORT version 11.0 20081105 on CentOS 5.3 64bit (but noticed this for some previous versions and other O/S). Anytime there is a lot of nested data type variables, the compiler comes to a crawl and uses a ton of memory, even when compiling in debug mode, which is usually a lot faster than optimized. I use nested data types to minimize memory usage as much as possible. So rather than having one six dimensional array with enough space to store any conceivable amount of data, I create a 6 level nested data type and only allocate what I need at each level. The only problem is slow compile times, sometimes in the range of 10-15 minutes per file.

Has anyone else had this problem and/or have an idea how to alleviate it (other than re-writing to get rid of the nested data types)? Maybe even a more basic question is whether this a problem or an unavoidable "feature"?

Thanks,

John
0 Kudos
2 Replies
Steven_L_Intel1
Employee
902 Views
We'll need a test case. I have not seen an issue simply with nested data types - there's probably something else relevant you haven't mentioned. Of course, I'd suggest trying with a current compiler - the one you are using is a year and a half old.
0 Kudos
jpapp
Beginner
902 Views
As is usually the case, the piece of code is proprietary and is a component within other coding, so it is hard to extract. I did some testing and found that in general, as the data type nesting gets more complex, the compiler slows down. If there isn't enough system memory and it has to go to swap, then things really slow to a crawl. Attached is the best I could do for an example. The code doesn't work but it does compile with the command:

ifort -fpp -Qoption,fpp,-w0 -no-vec -extend_source -o main.exe main.f

Comment out sections and see how the time is reduced/increased. Pretty much I think there is nothing that can be done. The compiler just takes a long time to compile this type of code.

Thanks,

John
0 Kudos
Reply