Hi, I'm new to this performance tuning world, and have just started my 30 day trial of VTune and Thread Profiler. I'm having lots of trouble getting it to run properly without crashing or doing weird stuff. I have gone through the Getting Started Tutorial with Primes and didn't have any issues with that, so I am prepared to be told that there is something wrong with the application that I am currently trying to tune.
First, some background information about my system. It is a brand-spanking new Dell Precision T5400, 3GB RAM, quad core Xeon system. I run both Visual Studio 2005 and 2008, and installed VTune with both IDE integration components.
I have run my initial tests with both IDEs, and have had the exact same results. I have also tried running VTune alone and specifying the executable.
Through VS2005 IDE
- Run sampling activity, started
paused, app eventually spontaneously wants to exit as if it's being sent
a WM_CLOSE message, even without ever starting the activity - Run
call graph for 300s, started paused, app reports DB error on startup. Then get a
runtime error, ESP corrupted. see callgraph_esp_corrupt.png -
Run counter for 60s, started paused, VS2005 reports an "internal error"
before app even starts up. see counter_vs2005_internalerror.png - Try to run the same counter activity from the toolbar, VS2005 immediately crashes -
Thread Profiler has some issues. VS2005 crashed during app execution, but app kept running. Although I got a VS2005 "crash", the IDE was still
running. Was able to gather data for a short period of time by
resuming and stopping in the middle of execution.. However, double
clicking on an underutilized thread in the profile view caused VS2005
Through VTune, VS2005-compiled app
- Call graph, 20s, start paused: app reports same DB error on startup with ESP corruption - Sampling, 20s, start paused: app shuts down spontaneously again -
Counter monitor also fails immediately. Error in log: "The Counter
Monitor collector is collecting data", followed immediately by "The
Counter Monitor collector failed to collect logged data. Make sure the
selected trigger(s) are working."
Through VS2008 IDE
- Call graph, 20s, start paused: worked
- Sampling, 60s, start paused: app shuts down spontaneously
- Counter, 60s, start paused, VS2008 crashes on start
Other than the call graph in VS2008, VTune had issues under both VS2005 and VS2008.
Is there any other source of information I can get from VTune to make it easier for people to help me figure out what's going on? I'm currently reading Intel's VTune Performance Analyzer Essentials, but haven't come across any helpful info regarding my problems.
In the meantime, I'll keep playing with Primes and the other example programs to get more acquainted with the tool. Any info that people here can provide me with would be really appreciated!
For what it's worth, in case of difficulty with thread profiler, if you haven't done so, you might want to try the less ambitious move by compiling and linking with /Qtprofile, running and reading the data collection file into VTune. If you can use OpenMP, linking with /Qopenmp-profile and reading the data collection file into VTune, or simply examining it with a text editor, should give more useful information. If you're not running a 64-bit version of Windows, you may find that useful for running VTune, even if you're not intending to build a 64-bit .exe. I would stick to running VTune outside VS, at least in cases of difficulty.
The application I am debugging is composed of an application, plus *several* DLLS, and optionally plugin modules. Do you think that some of the issues I'm having is related to not specifying /fixed:no for every module that the app loads? VTune itself hasn't complained about it, but maybe that is causing me some problems. At the moment, the activity I most want to run is sampling, but the application's behavior seems to change drastically when I enable that activity. Normally, it starts fine, but as soon as I use sampling, the application spontaneously shuts itself down.
For Call Graph and Thread Profiler, the standard approach when having problems is to lower the default instrumentation level, then raise it for specific modules that you're interested in (or you find the particular module that's causing a problem)
You might also try PTU - the stack sampling collector can give you similar information to call graph with less overhead. Available at http://whatif.intel.com
Are you running XP or Vista?
The /fixed:no option is probably not causing a problem with Sampling.
I would suggest submitting some of these issues to premier support (http://premier.intel.com). Particularly the one where Sampling causes the app to shut down.
First, there is no version 9.1, so I assume you mean version 9.0 Update 11.
"- Run sampling activity, started
paused, app eventually spontaneously wants to exit as if it's being sent
a WM_CLOSE message, even without ever starting the activity"
That is exactly what is happening if you are using the Quick Performance Analysis wizard to create the activity. Instead, use the Sampling wizard and ensure that "Stop collection after a duration of 20 seconds" is NOT checked.
If this option, or the "Terminate app when activity ends" option in the Sampling collector configuration", is checked and a duration specifed, then the VTune analyzer attempts to "terminate" the app by sending a WM_CLOSE message to the top level window.
Thanks for the tips, Mark. I'm downloading PTU now and will give it a whirl.
As far as the sampling shutdown problem goes, I think I've gotten past that by chance. During "normal" operation of the app, it's possible that a messagebox will pop up from another DLL if the network adapter isn't selected. By properly setting up my application so that msgbox doesn't appear, sampling no longer shuts down the application, which is great. So now I can acquire data for sampling, which is a lot farther along than I've gotten so far.
Call graphing still doesn't work because of a bogus SQL error that pops up. Under normal runs, that has never occurred, but it does with call graphing. Maybe I'll have better luck with PTU. I'm also inquiring on the DTL website to see if anyone has seen this before. Call graphing is somehow causing calls to SQLExecDirect to fail with SQL_ERROR. Odd.
I'm currently running Windows XP; silly me forgot to put that into my system description. Intel Premier support will still look at my problem even though I'm only running an evaluation version?
As far as the Quick Performance Analysis wizard goes, I don't think I was using that because I had read some posts before even using VTune that recommended the other analysis wizards instead. I could always go back to the app's previous state to confirm the shutdown behavior, though. In the sampling wizard, I don't see the checkbox that you referred to, but I am using the following options:
- EBS (don't calibrate sample after value) - sampling interval = 1ms - sampling buffer size = 2000KB - delay sampling unchecked - track thread creation checked - terminate application when activity ends checked - display sampling results over time checked - stop collection when application terminates checked - maximum samples collected unchecked
Just out of curiosity, does everyone here tune in release mode only? That's what I'm doing right now.
Ok, I will likely contact them. However, so far I have been really happy with PTU. I'm glad to see more and more companies embrace Eclipse as their IDE. I personally don't have much experience with Eclipse, but Intel did a really great job with their plugin, and I like it so much more than VTune. Of course, that could be because I don't have all of the crashing problems in PTU. ;)
One thing I haven't been able to figure out in PTU - is there a way to tell it to stop profiling when the application shuts down? Whenever I shut down my application, PTU launches it again. The only way I can stop profiling is to do it through PTU's stop button (which is fine as long as it works). Just curious.
FYI for anyone else that may have had issues with VTune and are reading this thread... I finally have call graph working on my system. I ended up modifying the activity properties to minimally instrument the modules in my application. Now I can call graph fine. I am now playing with specifying specific methods in my application, and it seems to be working.
I guess my next hurdle is to learn how to extract useful information out of all of this data. :)
If you have specified enough events that PTU or VTune has to perform multiple collection runs, it will restart the application when it dies, until all specified events have been tried. It's best to get the setup working first with just the default events.