Re: The strange performance of Visual C++ application
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
and if some processor core is available, it will use 100% of that core whatever it’s priority is – right?
Re: The strange performance of Visual C++ application
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.
Re: The strange performance of Visual C++ application
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).
Re: The strange performance of Visual C++ application
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
Re: The strange performance of Visual C++ application
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?
Re: The strange performance of Visual C++ application
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.
Re: The strange performance of Visual C++ application
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?
Re: The strange performance of Visual C++ application
Quote:
Originally Posted by
VictorN
Arjay, did you mean PostMessage?
Yes. Thanks Victor, I fixed it.