I have been using VTune for Windows for almost like 2 years now. I use to profile my code running on Linux systems (remote sampling). I am about to download VTUNE 3 fro Linux -- since it looks like most of the features have been extended to the linux version too. And eclipse is a new addition worth trying. Before I install and do stuff, I was just wondering if the new version allows one to automate profiling. I know older version did, but lacked a lot offeatures that I needed.So basically, whatI'm looking for is this. Can I issue a bunch of vtl jobs from command line using a script? I need to collect a lot of data and its been a test of my patience to sit and collect data all day long, in front of a windows machine. I wish I could automate it. And, is there a way to see the grand list of the available counters that you can use during profiling - like the equivalent of "Event List" in the windows version?
Message Edited by jayaprakashp on 01-31-200509:01 AM
First, if you want to see what sampling events are specific to the processor that you're working on, try this command:
$ vtl -help -c sampling | more
(I never remember that command, always have to check it out with a man page on vtl, $ man vtl...)
At the end of that output you'll get the list of all the events you can sample for.
Note that for a really good indepth explanation of each event, you'd want to examine the Reference Manual, which is an encyclopedia of event meanings and interrelationships. You can view that by bringing up your browser and viewing (default location):
You'll see a bunch of listings, primary events, secondary events, etc.
To answer your first question second, absolutely you can script vtl command in perl or shell or whatever you like. Very normal for our customers to do so, actually. You might couple a data collection activity with a viewing activity, like this sample shell script that I call myscript::
$ cat myscript
vtl activity -c sampling -d 30 -app /bin/myfiles/testing run
vtl view -ha -mn module1 >> mydata
In English, the two steps are: run a vtl sampling activity 30 seconds in duration on the binary called testing. Then, view the data showing me a hotspot analysis on the module named "module1" and append that information to my data file, named "mydata".
Run the script, vi the file mydata when you're done. Or you can run several sampling or callgraph activities in a row, and view the results live, at your leisure.
Also please note that you can also run remote data collections from one linux server to another using the command line and scripts as well. You do NOT have to use the GUI, you just put the target system's IP address into the line.
Here's a sample of that kind of syntax, which can easily be scripted:
vtl activity -c sampling,project1,18.104.22.168 -app /my/app,,/tmp,22.214.171.124 run
NOTE: no carriage return, this is all one line at your linux command line.
(In English: run a sampling activity named project1 on the remote server with ..82.106 ip address, on its application called /my/app, and use /tmp as a working directory on the same server.)
You get the idea. Script away, you're going to like it.
BTW, this command line processing has been available in the VTune analyzer on Windows since version 7.0! Although the usage is very similar, not all options are available on Windows and vice versa. See the documentation for specifics.
Thanks for your elaborate help. It was useful. I tried some priliminary scripts. In fact, things seem to have improved a lot in the Linux version of VTUne. I can now perform pretty much everything I want to do on the Linux side itself. Good.
Hi Dave: Thanks for the input. I have tried using thee command line processing in Windows for version 7.0. But my experience was not that pleasant. That's why I reverted back to the GUI based version. In any case, since my goal is to profile Linux based systems, I realized it makes more sense to run everything on the Linux side (writing and executing scripts is easier as well).
Thanks again for all the feedback.
Message Edited by jayaprakashp on 02-12-200501:06 PM
I will agree that the 7.0 implementation of the command line interface was less that stellar. However, version 7.2 is much improved and offers pretty much all that the Linux* version can do from the command line, if not more. Just FYI.