Microsoft Visual Studio 2010 & Intel® Visual Fortran exe runs slower than Linux ifortran exe does

[Bakhbergen]

One of my former colleagues gave me exe file and Fortran source code for it in 2012. According to the Make file included with his project, the colleague created the exe file on Linux ifortran.

As a Windows user, recently I created exe file for the same code using Microsoft Visual Studio 2010 and Intel® Visual Fortran 2013. After fixing a few errors and warnings in Debug mode, I have produced Release (Win32) mode executable. I have found that my exe runs significantly slower than my colleague's one does.

I have lost contact with the colleague. Does anyone know what may be causing this? I would appreciate any help.

[Steve_Lionel]

Can you show the command lines used in the makefile and in your VS project? How sure are you that you tested a Release configuration?

[Bakhbergen]

Steve, thank you for your response. As regards the makefile:

#.KEEP_STATE:
# Linux ifortran
#FFLAGS = -r8 -traceback -g -check bounds -O -Bstatic
FFLAGS = -r8 -O -Bstatic
# marathon Unix 
#FFLAGS = -r8 -O 
#FFLAGS = -O5 
#FFLAGS = -O -pg
#FFLAGS = -O -fast
#FFLAGS = -g
FSRCS = \
module11.f module12.f module1.f\

AND MULTIPLE OTHER *.f FILES\

FOBJS = $(FSRCS:.f=.o)
#FMOD_OBJS = module11.o module12.o module1.o
PROG = NAME.exe
FORT = ifort
$(PROG):  $(FOBJS)
	$(FORT) $(FFLAGS) $(FOBJS) $(FMOD_OBJS) -o  $(PROG)

[Bakhbergen]

My VS project has been built using Microsoft Visual Studio IDE in conjunction with Intel® Visual Fortran 2013:

 

[Steve_Lionel]

You haven't shown the Visual Studio options.  Can you attach the .vfproj file?

I will comment that you are using a seven-year-old compiler on Windows. I don't know which version you're using on Linux.

I also have to assume you are running the Windows and Linux programs on different computers. Are they the same model with the same processor and memory?

[Bakhbergen]

Steve, thanks.

I have tried to attach colleague's and my vfproj files below. It asks me to correct the following error and try again: “The attachments' *.vfproj content type (application/octet-stream) does not match its file extension and has been removed.” Now how can I send them to you?

I'm not using anything on Linux and Linux itself at all. I am just using the exe file created by colleague in 2012 for run and comparison of performance with mine. I'm running both executables on the same computer.

Please let me know if you need any clarification.

[Bakhbergen]

Colleague's and my vfproj files are attached below.

[mecej4]

I suspect that your narrative is not quite correct.

Unless your colleague had an Intel Fortran cross-compiler installed on Linux, (s)he could not have created a Windows EXE on a Linux system. In fact, if you are comparing two Windows EXEs, one that you built and one given to you by the colleague, it should not matter whether the latter EXE was produced on a native Windows PC or a virtual machine or an emulation layer such as Wine.

On the other hand, the use or presence of a makefile is not sufficient evidence that a Linux system was used.

You have said that the difference in run times is "substantial". Please be more specific.

[Steve_Lionel]

There's no Linux involved here - you're now indicating that your colleague used Windows to create the EXE. I also suspect that "your narrative is not quite correct".

[Bakhbergen]

mecej4, Steve_Lionel, thanks and apologize for the confusion due to my lack of knowledge about Linux.
To be more specific about the difference in run times for the same physical process:
- colleague’s exe has used 8008.719 sec of CPU time;
- my exe has used 11421.56 sec of CPU time.
Just in case I am open to your remote support using Windows desktop access software like TeamViewer.

[Steve_Lionel]

Are you and your colleague using the exact same compiler version? That is a significant difference, and a long run time (over three hours). How sure are you that there was no other activity on the system?  

Another possibility is that a slight difference in a key calculation might cause the program to run more steps - I have seen that before, especially for algorithms that look for convergence.

Sorry, nobody here is going to do remote assistance for you. It would be difficult to resolve a problem such as this when comparing against a pre-built executable.

[Bakhbergen]

I don't know if I and my colleague used the exact same compiler version. If in 2012 October Intel® Visual Fortran 2013 was available, then, probably, yes.
I run both executables on the same computer at the same time parallelly so, I think, other activities on the system influenced them approximately equally.
Numbers are the same (please see attached screenshot).
I asked this question because I thought that there may be some optimization tricks for release mode, which I didn't know.
Anyway thank you for dedicating your time and energy into this.

[Steve_Lionel]

The outputs are different (colleague's goes on longer) - is that just due to the way you showed us the output? 

You can enable a higher (O3) optimization mode and also choose, under Code Generation > Intel Processor-Specific Optimization "Same as the host processor /QxHost"). I think that was available in that old version.

That's the best I can suggest. 

[Bakhbergen]

Steve, yes. That is just due to the way I screenshotted the computation process in the first minutes. At the time of the screenshot, we have a long way to go yet regarding computation for both executables. As can be seen from the screenshot, colleague’s version leaves mine behind even it is started/launched a bit later.
Thank you for your valuable information.

[Bakhbergen]

Steve, your suggestion on enabling a higher (O3) optimization mode works, thanks.

As you suggested, I have made the following:
Optimization > Optimization "Maximize Speed plus Higher Level Optimizations (/O3)"
Code Generation > Intel Processor-Specific Optimization "The processor performing the compilation (/QxHost)"

The resulting executable runs faster than my previous executable.

[IanH]

---

@Bakhbergen wrote:

...I run both executables on the same computer at the same time parallelly so, I think, other activities on the system influenced them approximately equally...

---

Windows will give the process that it thinks is in the foreground higher priority access to resources.  Your results may vary depending on the console window you have activated.

[Bakhbergen]

IanH, thanks. I did a couple of test runs in order to check for Windows process priority access. Colleague's-Colleague's and My-My comparisons result in the same performance respectively (please see attached screenshots).

[mecej4]

Bakhbergen,

Earlier, you wrote "Just in case I am open to your remote support using Windows desktop access software like TeamViewer."

How about an alternative: your program appears to be a straightforward console application (character mode I/O, no GUI). If so, you may zip up all the source *.f files, plus any include files and data files, upload the Zip file to you Intel forum account or a cloud service such as Google Drive, Dropbox, etc., make the uploaded file public access, and post a link here.

Often, small changes to the algorithm are far more effective in speeding up a program than attempts to optimize using compiler options.

[Bakhbergen]

mecej4, your suggestion is appreciated. I agree with you. The thing is, distribution is permissible only with the consent of all coauthors.

[andrew_4619]

Does this program write a lot of data files? There are some differences in performance from some of the Intel compiler versions based on i/o default buffering behaviour. that might be a red herring but just a thought. https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-developer-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-buffered-specifier.html

[Bakhbergen]

andrew_4619, yes, the program writes quite a lot of data to output files. Thank you for this information.