Slow Fortran solution with Visual Studio 2015 and 2019 compared to 2005

[EduardoPerez]

At our company we do software development for internal use. We are not experts in the configuration of the tools we use and now we are struggling trying to change from VS2005 to VS2015 or VS2019 (with the respective Parallel and oneApi fortran extensions).

We have been using VS2005 to compile a Fortran program for long time.

Since 2016 we have tried to change to VS2015 or VS2019 but when we compile in any of those the debug and release built run extremely slow compared to the original (same code) compiled with VS2005.

We have tried to change different properties without success.

When we run the program with the compiled code with VS2005 it takes about 30 minutes to finish.

When we run the program with the compiled code with VS2015 or VS2019 it takes more than 24 hours to finish.

Thank you in advance.

[Ron_Green]

to make it more like VS2005, you are compiling the app in VS2019 with Configuration ia32 and Release configuration, yes?  

and you are running the code from the command line, yes?

[EduardoPerez]

Hi Ron.

We are compiling in 32 bit and have tried both Debug and Release configuration.

Also, we have tried to run it from the command line as well as from VS.

In all these scenarios we get the same timing.

Thanks

[mecej4]

I doubt that useful suggestions could be given before we have some specific pieces of information.

What is the CPU on which you run your programs? Which version of Windows? What does your program do (algorithm, application area, type of problem, etc.)?

Can you post a build-log file from VS2005, and another from VS2019? Can you strip your code down to a small enough size that you can post the source here, without making the problematic speed issue disappear?

[EduardoPerez]

Hi mecej4.

I am running the program in a CPU with the following specs: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz 3.70 GHz, 64.0 GB (63.9 GB utilizable), Sistema operativo de 64 bits, procesador x64, Windows 10 Pro V.21H1.

The program basically assembles a matrix which dimension varies depending on the size of the problem being analyzed. After assembling the matrix, it uses algebraic techniques to get a simplified solvable problem.

I'm attaching the build log files for both 2005 and 2019 respectively.

I'm not sure I understand your last query. The code is enormous.

When I'm debugging, it usually gets stuck at the same point (it seems it gets stuck but eventually the program continues). When I pause the debug at this point, It stops always at the same line: READ(LUNIT,ERR=999,IOSTAT=ID) (IAR(I),I=1,LEN).

At that point the step over goes to the disassembly window, and, if I hit continue and pause again, it stops at the same line as if it isn't advancing, but the value of I changes.

Thanks again.

[Ulrich_M_]

I have had success speeding up compilation by making sure all relevant files are in local (not network or dropbox-type) folders, which are not scanned by antivirus or other automatic services.

[mecej4]

Ulrich_M makes a good observation regarding the effect of using source files that are not local files on build speed. If the user's program creates or uses many files when it runs, the same remarks would also apply to those files and to program run times.

[EduardoPerez]

We have had a breakthrough in our attempt to solve the issue. We would like to get your feedback about it.

We got much better performance changing the default I/O BUFFERING from NO to YES.

When we searched about the OPEN: BUFFERED Specifier we found out that in VS2019 the 'YES' or 'NO' values for the BUFFERED Specifier apply for both WRITE and READ operations; however, in VS2005 those only apply for the WRITE operations (the Help Documentation only mentions WRITE operations).

In both versions the default value for the Specifier is 'NO'.

We believe that in VS2005 the READ operations were always treated with a BUFFER. ¿does anyone has knowledge about this?

[Steve_Lionel]

The Visual Studio version has no effect on how Fortran I/O works. Fortran I/O buffering HAS changed across Intel Fortran versions and there have been cases of poor performance and/or corrupted data. I don't see that you have identified which Intel Fortran versions you used in the two VS environments. There is no overlap in compiler versions supported in VS2005 and VS2019.

[EduardoPerez]

Hi Steve.

With VS2005 we use Intel(R) Fortran Compiler Integration for Microsoft Visual Studio 2005, 10.1.4161.2005.

With VS2019 we use Intel(R) Fortran Compiler - toolkit version: 2001.3.0, extension version 19.2.0062.16.

We also have VS2015 with Intel(R) Parallel Studio XE 2016 Update 3 Composer Edition for Fortran Windows Integration for Microsoft Visual Studio 2015, Version 16.0.0062.14. The application with this environment behaves the same as with the VS2019.

[Steve_Lionel]

OK - you're using the 10.1 compiler from 2006 or thereabouts. Buffering changed a LOT since then. Again, it has nothing to do with the environment and everything to do with the compiler and support library you are using. If buffering works for you, then by all means enable it.

[liuyapeng]

I have the same problem. When compiling Fortan programs with VS 2019+Intel Parallel Studio XE 2020, the compilation speed is very slow. It is not clear whether the computer (Intel(R) Core(TM) I5-6500 CPU @ 3.20ghz (4 CPUs), ~ 3.2ghz) is not performing well, or whether it is due to software configuration or installation.

[mecej4]

What you write about appears to be a different issue than that reported by EduardoPerez. His report was about slow I/O related to buffering. What you are writing about is slowness during compilation, not when running.

One possible cause: do you have the license for Intel Fortran managed by a remote server, or have the license file placed in a network directory rather than on a local HDD/SSD?

[liuyapeng]

Thank you for your reply, I will check the problem you mentioned. When I change this compilation option(Fortran>General>Multi-processor Compilation, change to 'Yes(/MP)'). Compilation speed has improved a bit.