Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26748 Discussions

Compiler Version 2016 two times slower than 2012

Hi As we switched to a newer version of the Intel Fortran Compiler (from 13.0.3600.2008 to 16.0.0063.14) we realized that our application became sigificantly slower. In order to identify the problem, we wrote a simple "Hello World" program (only that it writes 1 million times "Hello World" to a file). The benchmark results are: Old Version: 2.58sec or 41.2 Mbit/s write speed New Version: 4.77sec or 22.3 Mbit/s write speed Is there a way to get back to the original performance? Best regards Here is the "Hello World" test program:
      program WriteScratch

       Character*32 Test
       REAL     secnds,t0,t1,MBit,MByte

       Test=' '
      t0 = secnds(0.0)
      do i =1,1000000
      Write(11,*) 'Hello World'
      END DO
      READ(11,'(A32)') Test
      t1 = secnds(t0)
      write(12,10) t1
      write(12,20) Mbit
10    Format (' Dauer:',F10.3,' sec')
20    Format (' Geschwindigkeit:',F10.3,' Mbit/s')
9000  CLOSE(11)
9001  CLOSE(12)
      end program WriteScratch
0 Kudos
4 Replies
Black Belt

What are compile options are you using?

Is your example code really all that relevant to your production code?  I assume not - in which case the example isn't particularly useful.

The compiler's implementation of IO will have changed between those versions to support things like user defined IO. 

I think I've also seen changes in how files are buffered (but this isn't something that I've paid any attention to, and perhaps it doesn't apply to formatted sequential IO).  Have you experimented with the open specifiers and environment variables that affect buffering?  I suspect a program with so many small writes and reads would be particularly sensitive to buffering options.


I can also confirm significant performance loss due to file operations over that time. Adding "buffered" to all OPENs seems to have alleviated the issue.

Thanks for the quick answer. I tried with open( ... BUFFERED='YES') and I get very similar results as with the previous compiler version without the option. I then tried the environement variable "FORT_BUFFERED=YES" and it worked as well on my small hello world program (e.g. I get a 2 times speed up - back to the old compiler performance). Now actually my real problem was not in a "hello world" program, but I have a very old fortran code that is huge. It uses file I/O in many locations where nowadays a simple in memory solution would be best. All the time, even though it is not optimal, this was not an issue, as the total time spend was acceptable for the user and with each new compiler version and each new computer version, execution time decreased. The reason why I looked into the performance again was that on WINDOWS 10 on a network dirve (SMB Server) and the new fortran compiler version the execution time EXPLODED which means it was 200 times that of WIN7 and the old fortran compiler under the same conditions. Using the "hello world" example it nailed down to : a factor 2 due to the new compiler version and a factor of 100 for WIN7->WINDOWS10 on a network drive. Now I was hoping that it is an issue with the FORTRAN I/O Buffering and that resolving this would also resolve the WINDOWS10 issues. Unfortunately this is not the case. When I tried the environement variable "FORT_BUFFERED=YES" on the real world application I get only a slight speed-up (-10%). It looks like WINDOWS10 refused to buffer access to some SMB network drives. The first suspicion was the anti-virus, but the problem remained after switching it off and could be reproduced an many machines. Of course I know that the real solution would be, not to do any file access, but this would mean a huge modification to the old code. With the 200 times decrease in execution speed I feel like projected back to the middle ages. Has anyone have similar experience or even a "solution" to speed up small file access to WINDOWS10? Best regards
Black Belt

Andreas, if the burden of modifying the source code is the main obstacle to reducing the I/O penalty, perhaps you do not care much about the contents of the files that your application creates, and it may not matter if those files do not have shared access. If so, why not solve the problem by changing the location of those files to a local drive or even a suitably sized ramdisk?