How to improve calculation speed on virtual machines for Exe compiled by Intel Fortran XE2011?

How to improve calculation speed on virtual machines for Exe compiled by Intel Fortran XE2011?

We experience slow calculation speed on virtual machines with use of Exe compiled by Intel Fortran XE2011.

The application was for pure numerical calculation which has many do-loops and subroutines. There was no graphics or C or C++ involved.

Our facilities and compiled Exe:

Local desktop PC

(LDP)

Intel i5-2400 CPU @3.10 GHz, 4 GB RAM, 32 bit operation, Window 7 service pack 1

host machine of virtual machines

8 processors

virtual machine

(VM)

Intel i7-920 @2.7 GHz, 1 processor, 1GB Ram, 64 bit operation, window XP 2003 service pack 2

32xC.exe

by CVF ver 6.6

32xI.exe

64xI.exe

by Intel XE 2011 on the local PC with options of 'Maximize Speed', 'stack reserve size=10M', 'stack commit size=10M', /Qimf-arch-consistency:true /Qprec

CPU comparison (sec)

32xC.exe

32xI.exe

64xI.exe

LDP

1145

458

VM

1717 (stable)

630-2498 (not stable and slow sometimes)

547-1868 (not stable and slow sometimes)

May we know what was the reason and how to solve the problem?

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

What is the RAM size of the Host machine of virtual machines?
What is the processor model of the Host machine of virtual machines?
What is running on the Host machine of virtual machines while you are running your test program?

On the Host machine of virtual machines, can your run the performance monitor (not as a virtual machine, rather as a host application)? If you can, monitor page faults (aka swapping, paging). Make repeated runs, you see if you notice a corilation between number of page faults (during run) and run time of test program.

An additional source for "not stable" (inconsistent run times) is cache eviction. This can be caused between applications as well as between threads within an application (VTune might help you identify the cause).

Jim Dempsey

www.quickthreadprogramming.com

Login to leave a comment.