CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 23
  1. #1
    Join Date
    Jan 2012
    Posts
    7

    Unhappy 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

  2. #2
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: The strange performance of Visual C++ application

    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.
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  3. #3
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,395

    Re: The strange performance of Visual C++ application

    Quote Originally Posted by Kofan View Post
    ... 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?
    Last edited by VictorN; January 8th, 2012 at 06:42 AM.
    Victor Nijegorodov

  4. #4
    Join Date
    Jan 2012
    Posts
    7

    Re: The strange performance of Visual C++ application

    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.

  5. #5
    Join Date
    Oct 2008
    Posts
    1,456

    Re: The strange performance of Visual C++ application

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

  6. #6
    Join Date
    Jan 2012
    Posts
    7

    Re: The strange performance of Visual C++ application

    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.

  7. #7
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: The strange performance of Visual C++ application

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

  8. #8
    Join Date
    Oct 2011
    Posts
    23

    Re: The strange performance of Visual C++ application

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

  9. #9
    Join Date
    Oct 2008
    Posts
    1,456

    Re: The strange performance of Visual C++ application

    Quote Originally Posted by Kofan View Post
    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) ?

  10. #10
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    5,656

    Re: The strange performance of Visual C++ application

    Quote Originally Posted by He_That_Is View Post
    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"
    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...

  11. #11
    Join Date
    Jan 2012
    Posts
    7

    Re: The strange performance of Visual C++ application

    Quote Originally Posted by superbonzo View Post
    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.

  12. #12
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,395

    Re: The strange performance of Visual C++ application

    Quote Originally Posted by Kofan View Post
    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?
    Victor Nijegorodov

  13. #13
    Lindley is offline Elite Member Power Poster
    Join Date
    Oct 2007
    Location
    Seattle, WA
    Posts
    10,895

    Re: The strange performance of Visual C++ application

    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!

  14. #14
    Join Date
    Jan 2012
    Posts
    7

    Re: The strange performance of Visual C++ application

    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?

  15. #15
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: The strange performance of Visual C++ application

    Quote Originally Posted by Kofan View Post
    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?

Page 1 of 2 12 LastLast

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
  •  





Click Here to Expand Forum to Full Width

Featured