The strange performance of Visual C++ application

[Kofan]

I compiled a quite large C++ project in Visual Studio 2010 Ultimate using the Intel Composer compiler 2011, DirectX SDK (June 2010) and Intel TBB. After starting (either the Release or Debug assembly) directly from within Visual studio in debug mode (by pressing F5) the project runs much faster than when it started the outside of Visual studio (starting the .exe file directly).

Application type - event simulation of molecular dynamics. In general, even visually, i can see how the motion of particles (about 100 000 molecules) is much slower when you run the exe-file directly. Priority class for the application process is HIGH_PRIORITY_CLASS, work-threads of applications (responsible for the processing of events) have priority THREAD_PRIORITY_HIGHEST. As a result, when the application runs from the visual-studio (via F5) work threads are faster than running via Ctrl+F5 or exe-file directly
User - ADMINISTRATOR

What could cause this and how can it be fixed?

C++ compiler is configured for X86:

Platform: Win32
Target machine: MachineX86 (/MACHINE:X86)

My PC:

Processor - Mobile DualCore AMD Turion X2 Ultra ZM-80, 2100 MHz (5.25 x 400)
RAM - DDR2 4GB
Video - ATI Mobility Radeon HD 3650 (M86) 512MB
OS - Windows 7 Ultimate 64-bit

P.S. I'm sorry for my English - I'm from Russia

[D_Drmmr]

I suggest profiling your application to see where the difference comes from. VS2010 has special tools for profiling, but I've never used them. You can find tutorials online.

[VictorN]

... when the application runs from the visual-studio (via F5) work threads are faster than running via Ctrl+F5 or exe-file directly
User - ADMINISTRATOR

What could cause this and how can it be fixed?
...

Did you compare the Release or Debug builds?

[Kofan]

I compared the results for the Release version, because I disabled the optimization in the debug version. In my case Debug version is only for debugging the program and it runs slowly.

The main problem consist in the fact that when I run the Release Version from the Visual Studio via F5 (with binding debugger), it works much faster than if I run application via Ctrl+F5 (without binding debugger) or exe-file directly.

I would be very grateful for any help.

[superbonzo]

what happens when you set a normal priority class and level for your worker threads ? maybe, you're just experiencing some priority inversion ...

[Kofan]

The number of threads equal to the number of processor-cores. By setting a high priority threads - all cores busy my application and CPU load at 100%. If the thread priorities are normal CPU load only 50-60% because in fact some kernel idle, and the program runs very slowly.

[Arjay]

Hopefully with the threads set to highest priority in your application, you don't plan on running any other application.

[superbonzo]

The number of threads equal to the number of processor-cores. By setting a high priority threads - all cores busy my application and CPU load at 100%. If the thread priorities are normal CPU load only 50-60% because in fact some kernel idle, and the program runs very slowly.

my question was: do you see the same with/without debugger behavior when using normal priorities ? I ask, because if high priority threads share resources with lower priority threads then this may result in a worse overall performance due to the former excessively waiting for the latter ( aka priority inversion ) ...

for example, in post #1 you alluded to "visually" seeing the slowdown of your program, so, do you have a set of (high priority) worker threads and a (normal priority) gui thread visualizing the data ? if yes, does the total number of threads (workers+gui) equal the avaliable cores ? are you sure the slowdown isn't just due to the gui becoming unresponsive (and/or the workers sharing data with it) ?

[VladimirF]

The number of threads equal to the number of processor-cores. By setting a high priority threads - all cores busy my application and CPU load at 100%. If the thread priorities are normal CPU load only 50-60% because in fact some kernel idle, and the program runs very slowly.

This doesn’t make much sense.
You are saying that your threads (with normal priorities) are NOT utilizing CPU at 100%? What are they waiting for if no one else is using that CPU?
It sounds like you don’t have enough threads running simultaneously.
For example, if I create a busy thread doing something like

while(true)
    i++;

and if some processor core is available, it will use 100% of that core whatever it’s priority is – right?

[He_That_Is]

If it says Microsoft on the box, there is sure to be trouble inside . . .

[VladimirF]

If it says Microsoft on the box, there is sure to be trouble inside . . .

"If you can't say something nice, don't say nothing at all"

[Paul McKenzie]

within Visual studio in debug mode (by pressing F5) the project runs much faster than when it started the outside of Visual studio (starting the .exe file directly).

Well to me, it would be unexpected that an application running under a debugger (or any integrated environment) would run at the same speed as running straight from the command prompt or from Windows Explorer.

The debugger has to load symbols, output messages to the VS output window, etc. It would be natural to suspect that running under a debugger should add some overhead somewhere.

Read this:

http://blogs.msdn.com/b/larryosterma...heisenbug.aspx

Maybe that explains your issue?

Regards,

Paul McKenzie