-
January 11th, 2012, 10:51 AM
#16
Re: The strange performance of Visual C++ application
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?
Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
Convenience and productivity tools for Microsoft Visual Studio:
FeinWindows - replacement windows manager for Visual Studio, and more...
-
January 11th, 2012, 12:47 PM
#17
Re: The strange performance of Visual C++ application
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.
-
January 12th, 2012, 11:00 AM
#18
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).
-
January 12th, 2012, 11:29 AM
#19
Re: The strange performance of Visual C++ application
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
-
January 12th, 2012, 12:09 PM
#20
Re: The strange performance of Visual C++ application
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:
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?
Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
Convenience and productivity tools for Microsoft Visual Studio:
FeinWindows - replacement windows manager for Visual Studio, and more...
-
January 12th, 2012, 12:30 PM
#21
Re: The strange performance of Visual C++ application
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.
Last edited by Arjay; January 12th, 2012 at 03:27 PM.
-
January 12th, 2012, 12:34 PM
#22
Re: The strange performance of Visual C++ application
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?
Victor Nijegorodov
-
January 12th, 2012, 03:28 PM
#23
Re: The strange performance of Visual C++ application
Originally Posted by VictorN
Arjay, did you mean PostMessage?
Yes. Thanks Victor, I fixed it.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|