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

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

Bakhbergen
Novice
4,231 Views

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.

0 Kudos
41 Replies
Steve_Lionel
Honored Contributor III
2,438 Views

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?

0 Kudos
Bakhbergen
Novice
2,432 Views

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)

 

0 Kudos
Bakhbergen
Novice
2,427 Views

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

Release - 1.png

Release - 2.png

0 Kudos
Steve_Lionel
Honored Contributor III
2,407 Views

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?

0 Kudos
Bakhbergen
Novice
2,387 Views

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.

0 Kudos
Bakhbergen
Novice
2,375 Views

Colleague's and my vfproj files are attached below.

0 Kudos
mecej4
Honored Contributor III
2,361 Views

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
Honored Contributor III
2,347 Views

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".

0 Kudos
Bakhbergen
Novice
2,336 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
2,330 Views

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.

0 Kudos
Bakhbergen
Novice
2,320 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
2,313 Views

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
Novice
2,272 Views

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.

0 Kudos
Bakhbergen
Novice
2,158 Views

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.

 

0 Kudos
IanH
Honored Contributor II
2,303 Views

@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.

 

0 Kudos
Bakhbergen
Novice
2,249 Views

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).

0 Kudos
mecej4
Honored Contributor III
2,241 Views

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.

0 Kudos
Bakhbergen
Novice
2,232 Views

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

0 Kudos
andrew_4619
Honored Contributor II
2,221 Views

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

 

0 Kudos
Bakhbergen
Novice
2,207 Views

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

0 Kudos
Reply