Extremely long compile time with ifort 16.0.1 vs 15.0.3

[lopes8070]

Steve (or whoever gets this), we recently switched compilers from 15.0.3 to 16.0.1 and are now experiencing a significant (catastrophic) increase in compile time.  On a linux box, compile times went from 5 minutes to 40-50 minutes.  Are there any other reports of this?  I have given you our entire code in the past when we experienced this with 13 or 14 version compiler a few years ago (~4 years I think). Might be worthwhile to do something similar here.  Just wanted to get your take on it.

On a side note, we also see a few "*** glibc detected *** /usr/local/intel/compilers_and_libraries_2016.1.150/linux/bin/intel64/fortcom: free(): invalid pointer: 0x000000000469a060 ***" during compilation (and with version 15 compiler as well) but the code operation seems unaffected.

[lopes8070]

Correction, looks like the compiler is hung.  It is getting close to finishing the compilation but seems to be stuck.  So 40-50 minutes may be much much longer.

[Steven_L_Intel1]

I haven't been able to find any reports of such a problem in the 16.0 compiler. Can you give me a reported issue number I could check out? I will need to know exactly what options you use to compile and which source(s) are taking longer.

[jimdempseyatthecove]

The newer compiler may be (by default) enabling multi-file Inter-procedural optimizations. Try disabling that with the appropriate command line option.

Another possibility may be the output files (including temporaries) are being scanned by your Antivirus program, and this is interfering with the build. You can try setting the AV to exclude your intermediary and output folders.

Jim Dempsey

[lopes8070]

Why would the AV scan files from 16.0.1 and not 15.0.3?  We are not running anti-virus on the machine.

This is a typical compile command:

ifort -warn errors -warn all -free -fpp -fPIC -m64 -O0 -fp-model source -CB -g -traceback  -module Mission -c -Tf MissionClass.f03 -o MissionClass.o

I've removed a bunch of our include commands (-I/dir) and other application specific preprocessor arguments from the compile command to make it simpler.  The compile command is identical between 15 and 16.  The files themselves contain extended classes and other 2003 stuff (as compared to old FORTRAN77).

The previous time I provided the code was a long time ago and I've lost the record.  Also, the forum interface was completely different (maybe the forum is another interface for preferred members or something).

[lopes8070]

The code is ANOPP2, maybe you can search on your end for the previous tickets while I search on mine.  I would have to provide you an updated code but that could at least get us started if needed.

[lopes8070]

Did some digging in our issue tracking software from 4 years ago and it looks like we provided you guys the code and you provided us with version 13.0.0 beta and asked us to use an undocumented switch "-switch cq235485" which helped us with some speed up issues.  The issue was fixed in a later update and we no longer needed the switch.  Again, I am not sure if the issue here is related to that issue.  The date was around 08/06/12 and I was talking with a Martyn, sorry don't know the last name.

[Steven_L_Intel1]

Please file a new case with Intel Premier Support and attach your current sources.  Previously you dealt with Martyn Corden. Most likely your new issue is not related to the earlier one.

[lopes8070]

Steve,

Thanks.  We don't require 16 right now so this isn't catastrophic. However, we do plan on keeping up to date, so I am glad a checked.  If a solution is found, will this thread be updated for anyone who runs into this in the future?

[Steven_L_Intel1]

If you file an issue and tell me the number, I'll associate this thread with it and will communicate any update.

[lopes8070]

Issue ID : 6000153493

[jimdempseyatthecove]

Not that this matters any more... (since it is not an AV issue)

>>Why would the AV scan files from 16.0.1 and not 15.0.3?

The rationale was: It is not a case that the AV would do anything different, it is a case that a mode in a file open internal to the compiler may have changed between versions. If one open mode permits sharing and the other not, then the AV opening the file may interfere with one compiler and not the other.

Jim Dempsey

[Steven_L_Intel1]

This is on Linux, so not likely that there's an AV scanner (not that Linux systems don't get viruses, but scanners are unusual there.)

It would be interesting to know if the slowness goes away if optimization is disabled. Thanks for the Premier issue, but please provide the sources and build commands/makefile there as well.

[lopes8070]

Steve, exactly what would you like me to add to the compile command.  We can test out a few things in parallel to the premier if you'd like.

[Steven_L_Intel1]

Now that I have your sources, I will do the experiments. Thanks.

[Wukie__Nathan]

I haven't done a lot of investigation into this, but I also experienced a very significant hit in compile time switching to ifort 16.0.1 from 15.0.3.

[SL00]

Dear all,

I am now experiencing the same long compilation time as well.

real 13m49.774s

user 8m10.299s

sys 0m5.653s

Here is the product information,

Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.1.163 Build 20171018

Configuration of my laptop,

Memory: 16GB
Processor: Intel® Core™ i7-5600U CPU @ 2.60GHz × 4
OS type: 64-bit
Disk: 250GB SSD

My code is written in pure Fortran and has 332,333 lines.

Any idea about this?

Cheers,

Xiangyu

[Steve_Lionel]

Duplicate of https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/624156#comment-1918436