The strange performance of Visual C++ application

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

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.

Quote:

---

Originally Posted by Kofan

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

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.

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

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.

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

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

Quote:

---

Originally Posted by 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.

---

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

Quote:

---

Originally Posted by He_That_Is

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" :)

Quote:

---

Originally Posted by superbonzo

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

---

When using normal thread priority (priority of the process is high), the situation has not changed.
My application works as follows: while working work-threads, interface-thread is waiting. When all worker threads have completed, the interface-thread renders the data, again starts work-threads and waits. Thus the number of concurrent threads is less or equal to number of the cores.
All threads always have the same priority.

Quote:

---

Originally Posted by Kofan

My application works as follows: while working work-threads, interface-thread is waiting. When all worker threads have completed, the interface-thread renders the data, again starts work-threads and waits. .

---

What is your UI thread waiting for? Why?

Do you use any environment variables to enable or disable accelerations? The environment variables are treated slightly differently when you are debugging vs starting normally.

Specifically, unless this has been fixed since I observed it, if one Windows environment variable uses another, then the "lower-level" one must come first alphabetically during normal operations, but not when using the debugger!

The algorithm of event-driven programming is such that, at first the events are processing and then drawing the result data. Therefore, when work-threads are processing an events interface-thread is waiting, and then drawing new result data.

Lindley, сan You explain more about the environment variables, because I do not use them anywhere in the code explicitly. Can they be used by the Intel-compiler implicitly?

Quote:

---

Originally Posted by Kofan

The algorithm of event-driven programming is such that, at first the events are processing and then drawing the result data. Therefore, when work-threads are processing an events interface-thread is waiting, and then drawing new result data.

---

Waiting is different than being blocked (when blocked no messages are being pumped in the ui thread). It's not clear if your ui thead is blocked. Also, how are you synchronizing the data that is shared between the worker threads and the ui thread?

Quote:

---

Originally Posted by 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.

---

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

Code:

---

while(true)
    i++;

---

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

Quote:

---

Originally Posted by Kofan

Lindley, сan You explain more about the environment variables, because I do not use them anywhere in the code explicitly. Can they be used by the Intel-compiler implicitly?

---

Presumably the issue isn't with the compiler, or else you wouldn't be seeing different behavior during two different runs with the same executable.

It's possible that one of the libraries you are using uses environment variables in some way. Check their docs.

The interface-thread is synchronized with the work-threads using "join" method of std::thread (tbb::thread) class. Shared data synchronized with tbb::mutex.

VladimirF, if the thread has the highest priority, it wil get the next quantum of CPU time. Otherwise, a thread can wait long enough, because the processor will work with other threads that have a higher priority (it can be the OS-threads or threads of other applications).

Quote:

---

Originally Posted by Kofan

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

Quote:

---

Originally Posted by Kofan

VladimirF, if the thread has the highest priority, it wil get the next quantum of CPU time. Otherwise, a thread can wait long enough, because the processor will work with other threads that have a higher priority (it can be the OS-threads or threads of other applications).

---

As I asked above:

Quote:

---

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?

---

Quote:

---

Originally Posted by Kofan

The interface-thread is synchronized with the work-threads using "join" method of std::thread (tbb::thread) class. Shared data synchronized with tbb::mutex.

---

join should not be used in the ui thread because it blocks the ui thread and prevents it from pumping messages as mentioned earlier.

The recommended approach is to have the worker thread use a user defined message and PostMessage to signal the ui thread when the work has completed.

Quote:

---

Originally Posted by Arjay

...
The recommended approach is to have the worker thread use a user defined message and sendmessage to signal the ui thread when the work has completed.

---

Arjay, did you mean PostMessage?

Quote:

---

Originally Posted by VictorN

Arjay, did you mean PostMessage?

---

Yes. Thanks Victor, I fixed it.