Why does my .exe only use 50-80% CPU when executing?

[Leigh_Wardle]

Hi all,

I am running Intel Visual Fortran Compiler Professional Edition for Windows v. 10.1 on Windows XP Pro SP2.

My PC CPU is a Intel Core 2 Duo E4500 @ 2.2 GHz.

I have compiled a few applications, for example, the Double Precision Whetstone (A001) (from http://www.netlib.org/benchmark/whetstoned )

I have used two sets of compiler options:

• Defaults
• Optimized (I tried turning on every optimization that I could see).

For none of these compiler options does the %CPU used when executing exceed 50-80%.

I have tried creating Console and Quick Windows targets - this doesn't seem to influence the %CPU very much.

What options do I need to use to make .exe files that will use close to 100% of the CPU cycles?

Thanks in advance...

Regards,

Leigh

[DavidWhite]

Leigh,

Have you built this for parallel processing? If not, then one core at 100% capacity = 50%. If the program only has one thread running this is the maximum you can achieve. Multiple threads can push it higher, depending on the structure of the problem, memory access may limit the CPU availability (others, more expert on this will probably comment further).

David

[Leigh_Wardle]

Quoting - David White

Leigh,

Have you built this for parallel processing? If not, then one core at 100% capacity = 50%. If the program only has one thread running this is the maximum you can achieve. Multiple threads can push it higher, depending on the structure of the problem, memory access may limit the CPU availability (others, more expert on this will probably comment further).

David

Hi David,

Thanks for the feedback.

When the .exe files run I can see that both cores are using about 50-80% of CPU cycles.
(maybe that's what you get when the app is compiled for a single core?)

Is is possible to automatically build an app for parallel processing?

Regards,

Leigh

[onkelhotte]

Quoting - Leigh Wardle

Hi David,

Thanks for the feedback.

When the .exe files run I can see that both cores are using about 50-80% of CPU cycles.
(maybe that's what you get when the app is compiled for a single core?)

Is is possible to automatically build an app for parallel processing?

Regards,

Leigh

You have to activate Parallelization in the Project Properties -> Fortran -> Optimization. This feature parallizes all loops, that wont depend on each other (result(i) = result(i-1) + x cant be parallelized, result(i) = x(i) * y(i) can be parallized).

So you get a "multi threaded" application without changing your code. If you want more parallelization, you have to use OpenMP or you have to deal with threads.

When you have a single threaded process, Windows shifts the thread to both cores, but effectively it uses only 50% of it on a dual core system or 25% on a quad core system.

Markus

[Leigh_Wardle]

Quoting - onkelhotte

You have to activate Parallelization in the Project Properties -> Fortran -> Optimization. This feature parallizes all loops, that wont depend on each other (result(i) = result(i-1) + x cant be parallelized, result(i) = x(i) * y(i) can be parallized).

So you get a "multi threaded" application without changing your code. If you want more parallelization, you have to use OpenMP or you have to deal with threads.

When you have a single threaded process, Windows shifts the thread to both cores, but effectively it uses only 50% of it on a dual core system or 25% on a quad core system.

Markus

Hi Markus,

Parallelization was activated in the Project Properties -> Fortran -> Optimization.

I guess these results show that the Double Precision Whetstone (A001) code doesn't benefit from automatic parallelization.

I will look at using OpenMP and thread analysis on my real world applications.

Regards,

Leigh

[Steve_Nuchia]

There is a process property known as "processor affinity" that can be set to keep a job running on one core or one CPU. Sometimes this can help, as it keeps the cache primed more effectively than when the job jumps around from core to core or chip to chip. It can be even more important in NUMA (non-uniform memory architecture) machines.

But for typical workloads it's hard to measure an affinity effect. Definitely second (or higher) order.