Intel Software Network articles feed

Use VTuneAPI in your code to profile without launching VTune(TM) Analyzer

Thu, 15 Oct 2009 02:26:27 -0700

Intel(R) VTune(TM) Performance Analyzer provides VTuneAPI to allow profiling which is controlled by the user. The objective is not to collect unreasonable samples in the portion of user's code (usually the code looks like to call 3rd-party libraries, system functions, etc) when data collecting

Article <<An Introduction to Sampling and Time>> introduced how to use Pause and Resume API at page 8. However it also informed the user that checking "Start with Data Collection Paused" should be set on User Interface at page 9.

Believe me that VTune(TM) Performance Analyzer can not be launched when executing user's code which has VTune API calls, and you can get result file which can be analyzed on VTune(TM) Analyzer later.

How smart it is! How simple it is! You don't need to run VTune(TM) Analyzer to get performance data. Everything is controlled by the user, including Sampling Configure.

See below example -

// testVTuneAPI.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "VtuneApi.h"

int _tmain(int argc, _TCHAR* argv[])
{
U32 u32Return;

VTUNE_EVENT events[] = {
         { 10000, 0, 0, 0, "CPU_CLK_UNHALTED.CORE" }, // Sample After Value, Reserved, Reserved, Return Status, Event Name - my system is Intel(R) Core(TM) 2 Duo
         { 10000, 0, 0, 0, "INST_RETIRED.ANY" },             //  Use "vtl query -c sampling" to know all supported events in the system, in command prompt
     };

     U32 numEvents = sizeof(events) / sizeof(VTUNE_EVENT);
     VTUNE_SAMPLING_PARAMS params = {
         sizeof(VTUNE_SAMPLING_PARAMS),
         sizeof(VTUNE_EVENT),
         0, // sampling options
         0, // reserved
         0, // If 1, start sampling in pause mode
         0, // maximum number of samples to be collected.
         1000, // number of samples per buffer
         40,  // the sampling interval in milliseconds
         1, // "1" for event based sampling
         numEvents,  // number of events
         events, // event list array
         "results.tb5", // result file with simple or full path
         0, // reserved
         0, // "1" - generate a count file "tb5Filename.txt"
         "" // CPU mask
     };

     u32Return = VTStartSampling(¶ms); // start sampling since it is not in pause mode
     if (u32Return) {
         printf("Can't start sampling\n");
         exit(0);
     }
     for (int i=0; i<10000000L; i++); // do some work, data is captured

VTPauseSampling(); // pause data collection

for (int i=0; i<10000000L; i++); // do some work, data is NOT captured

     VTResumeSampling(); // resume data collection

     for (int i=0; i<10000000L; i++); // do some work, data is captured again

     u32Return = VTStopSampling(1); // stop collecting data and write result into TB5 file, use VTune(TM) Analyzer to import it!

     if (u32Return) {
         printf("Can't stop sampling\n");
         exit(0);
     }

return 0;
}

Where are my threads?

Wed, 30 Sep 2009 04:05:20 -0700

One common question developers ask is how their parallel workload is distributed or scheduled across the available cores/processors.

Intel® VTune^TM Performance Analyzer comes into help and makes such analysis easy. The event-based sampling (EBS) technology identifies system-wide software performance problems by sampling processor events, such as clockticks and cache misses (Figure 1). From the EBS data, you can determine which process, thread, module, function, and source line in a given application generated particular events. By leveraging this technology you can see how many events were sampled on each core as well as which thread generated them.

Figure 1

The Show/Hide CPU Information button in the sampling toolbar displays collected samples and events per processor in the Process, Thread, Module, and Hotspot sampling views (Figure 2).

Figure 2

We now know that this particular program (sort_mt1.exe) was executed on 2 cores and we can see the number of samples collected on each core. But what we don't know yet is how many threads this application created and how the threads executed on these cores. Selecting the Thread view when CPU button is also selected will show us the desired information. Figure 3 tells us that sort_mt1.exe created 2 threads (thread18 and thread 13) and each thread was executed on both cores (OS scheduled these threads to run on each core) during the analysis. If you look at the clockticks (CPU_CLK_UNHALTED.CORE) for thread18, it becomes clear that this particular thread was executed on each core while running most of the time on Processor 0.

Figure 3

If you are still curious and would like to see how these samples are distributed over time per thread and per core then the sampling over time (SOT) view can help you. By selecting SOT view in thread view (or in any other view) the samples collected will be displayed per thread and/or core(Figure 4). The view seen in Figure 4 is useful for many reasons. The SOT view can help you:

•· see how OS scheduled the threads to run,

•· identify scheduling problems (Figure 5),

•· identify load balancing issues among threads (Figure 6),

•· and correlate micro-architectural problems.

Figure 4

Figure 5: Manually setting thread affinity can create problems. Each thread is scheduled/pinned to the Core/Processor 0.

Figure 6: SOT showing a load balance issue.

To make sure that all functions show up in call graph

Wed, 09 Sep 2009 12:33:44 -0700

Problem :

During generation of call graph, Instrumentation Level to “All functions” is specified (function in the function list is checked), but the function does not show up in the call graph function list after data collection is done.

Resolution :

It is possible that application compiled without debug information or base relocation information, so try to recompile executable file with these options.

Example (Windows*):
Debug info turned on -- [Debug Information Format]=[Zi],
In Linker option [Generate Debug Info]=[Yes],
Turn on base relocation info [Fixed Base Address]=[No]

--or in command-line /Zi /DEBUG /fixed:no ("/fixed:no" is for Microsoft* Visual Studio*)

I would also make sure that this function is really called in the given workload using debugger or some trace output.

It is recommended to only use “noinline” keyword for C++ code if it is important to see this function in optimized code.

Call graph may appear to provide incorrect results for calling sequences in some cases. The reason for this is that call graph support is based on binary instrumentation, and therefore only instrumented functions are reported in the call graph results. There can be several reasons why a function may not be instrumented:

• There is no symbol for the function in the binary (the image is stripped).
• The first basic block of the function is smaller than five (5) bytes.
• The function is inline and therefore doesn't exist in the binary.
• The function is called via jump instruction rather then call instruction

You can fix the case described in the first bullet with instructions provided in the first paragraph. The fact that you see this function in the instrumentation list and is able to check/uncheck this function (Activity Properties -> Call Graph -> Configure -> Functions button) means it most probably has symbols and it’s instrumentable. So make sure your function is not inlined in your binary and is not invoked via jump instruction.

If your workload is not very long and you are doing algorithmic optimization it seems to be reasonable to turn off optimization to see all the functions in call graph. You can use sampling to find the real hot-spot and call-graph to better understand the nature of this hot-spot. Call Graph is very suitable tool for algorithmic and workflow optimization on non-optimized (by compiler) application. The next step is compiler optimization and using VTune analyzer Sampling tool for getting more speedup. After callgraph analysis is done it makes sense to build the optimized version again to understand the real performance gain.

One of possible callgraph usages can be in learning the application workflow. In this case it does not matter if it is optimized. The more information we have and the more it is accurate – the better.

(O3), (O3, no inline), (O2) can be useful for different optimization phases. /O3 is pretty aggressive optimization option and ‘/Od /Ob0’ (is no optimization and no inline) in the compile icl command. (icc = "-O3" & "-O0 –fno-inline" on Linux)

You can also use /Ob1 with /O2 or /O3, please see http://software.intel.com/en-us/articles/hot-functions-cant-be-displayed-in-vtunetm-performance-analyzers-report/

Remote VTune Call Graph collection on Linux and symbolic link for shared object file

Thu, 16 Jul 2009 04:37:49 -0700

When analyzing an application that contains shared object files with VTune Call Graph remotely, setting a symbolic link for .so file as module of interest (MOI) might produce Call Graph error notification “Cannot find *.so file”. This is due to limitation of the Call Graph instrumentation engine which is not able to identify absolute path to the linked object. The workaround would be either using hard links or setting absolute path to the original .so file as MOI.

In case of using GUI wizard for creation Call Graph activity, there will be error message that identifies the symbol link as not executable file:

Performance Tools for Software Developers - What is new in VTune™ analyzer 9.1?

Fri, 19 Sep 2008 00:00:00 -0700

Windows*

Support for profiling runtime generated and interpreted code (JIT Profiling API Support).
Support for VTune™ Performance Analyzer Reader/Writer API (TBRW) This API enables you to read and write persisted data in an on-disk format that is compatible with the VTune™ Performance Analyzer.
Microsoft* Symbol Server support. You can now specify paths to Microsoft symbol server using the standard format. Use this feature if you need debug symbols for system modules.
GNU* debuglink support. The VTune analyzer supports debug information for Linux OS modules saved both with the module, or as a separate file. You can store the debug information file near the corresponding module, or specify the path to a directory with the debug information files in the search directory list for symbol files.
More information on the VTune™ analyzer 9.1 for Windows

Linux*

JIT Profiling API support
The VTune analyzer now supports profiling runtime generated and interpreted code. See the jit_profile_API.pdf file for details.
GNU* debuglink support
The VTune analyzer supports debug information for Linux OS modules saved both with the module or as a separate file. You can store the debug information file near the corresponding module, or specify the path to a directory with the debug information files in the search directory list for symbol files.
VTune™ Performance Analyzer Reader/Writer API (TBRW) support
This API enables you to read and write persisted data in an on-disk format that is compatible with the VTune™ Performance Analyzer. See the TBRW.pdf file for details.
More information on the VTune™ analyzer 9.1 for Linux

Intel® VTune™ Performance Analyzer for Linux* - How do I Supply Arguments for the Application to Run Under the Analyzer?

Fri, 19 Sep 2008 00:00:00 -0700

Symptom(s):

The VTune™ analyzer complains of a "Syntax Error" when you attempt to specify arguments or parameters to the application on the vtl command line.

Solution:

Use comma separation for arguments. For example,

vtl activity -c sampling -app /bin/ls,-Fa,/home run

will cause the analyzer to launch `/bin/ls -Fa /home'. No spaces are allowed before or after the commas.

Alternately, you can enclose all application arguments within double quotes, e.g.,

vtl activity -c sampling -app /bin/ls,"-Fa /home" run

Note that no spaces are allowed after the comma following the application name.

Operating System:

SUSE* Linux

Intel® VTune™ Performance Analyzer for Linux* - Documentation and command-line help

Fri, 19 Sep 2008 00:00:00 -0700

The documentation for the Intel® VTune™ Performance Analyzer for Linux* is presented in these formats:

Documentation Index
Readme File
Installation Guide
Administrator's Guide
Readme File for the VTune Analyzer Remote Agent
Command-line Help
Man Pages
HTML Reference, User's Guide and Getting Started Tutorial for vtl
Integrated Eclipse platform environment help

Command-line Help

Enter vtl -help to view command syntax and options for vtl.
Enter vtl -help -c where is either callgraph or sampling, for detailed help on collecting data.
Enter vtl -help -v where is either callgraph, sampling or source, for detailed help on viewing data.
Enter ActivityController -help to view command syntax and options for the ActivityController.

Manual Pages

To view manual entries for the VTune analyzer, enter the appropriate command:

man vtl for the vtl command man page
man vtlec for the vtlec command man page
man ActivityController for the ActivityController man page
man sampling for the sampling collector man page
man callgraph for the callgraph collector man page
man source or man 7 source or man code for the source view man page

Note: To view the man pages in the local language, set the system variables LESSCHARSET and LANG as follows: LESSCHARSET=utf-8
LANG=zh_CN.utf8

HTML Documentation

The HTML documentation for the VTune analyzer consists of these components:

Documentation Index. Open this document in the browser to view the list of available documentation. This document is available at < install_dir>/doc/doc_index.htm.
VTune(TM) Performance Environment User's Guide. To access the guide, launch the index.htm file from the /doc/users_guide subdirectory.
Reference Guide. To access the reference, launch the index.htm file from the /doc/reference subdirectory.
Getting Started Tutorial. To access the tutorial, launch the index.htm file from the /doc/training/gs_vtune subdirectory.
Java* Managed Run Time Environment Frequently Aske d Questions. To access the document, launch java_faq.htm file from the directory.
These Release Notes

Where: is the installation directory. The default installation directory is: /opt/intel/vtune.

Viewing HTML Documentation

The HTML documentation can be viewed with any web browser, although a browser that supports HTML 4.0 is recommended. Older versions of browsers (especially Netscape* and Konqueror*) may not display some of the HTML documents correctly.

Integrated Eclipse Platform Environment Documentation

The VTune analyzer documentation in the integrated Eclipse platform environment is available from the Eclipse user interface. Go to Help » Help Contents and click to expand the following books: VTune™ Performance Environment, VTune™ Performance Analyzer or VTune™ Performance Analyzer Reference.

Intel® VTune™ Performance Analyzer for Linux* - Java* Development Kits (JDKs)

Fri, 19 Sep 2008 00:00:00 -0700

The VTune analyzer in the integrated Eclipse platform environment has been tested for operation on the following JDK:

BEA* JRockit* 5.0

The VTune analyzer has been tested for profiling under the following JDKs. The latest releases of these JDKs may be used:

On IA-32 systems:
Sun* J2SE 5.0 and 6<
IBM* JDK 1.4.2 and 5.0
BEA JRockit 1.4.2, 5.0 and 6

On Intel® Itanium® architecture systems:

IBM JDK 1.4.2
BEA JRockit 1.4.2 and 5.0

On systems with Intel® 64:

Sun J2SE 5.0 and 6
BEA JRockit 5.0 and 6
Note: The VTune analyzer will crash under Eclipse if you run it with BEA JRockit 5.0 under Red Hat Enterprise Linux*

4.0 for Intel® 64 - Do one of the following to avoid this situation:

Install the errata kernel for Red Hat Enterprise Linux 4.0
Use Red Hat Enterprise Linux 4.0 U1
Use the Sun JVM 5.0

Intel® VTune™ Performance Analyzer for Linux* - Temporary and project files for VTune™ Analyzer for Linux* location

Fri, 19 Sep 2008 00:00:00 -0700

There are several places where VTune™ analyzer for Linux* stores its temporary and project files: user files, instrumented binaries for the current user, and symbol cache files for all VTune users. The default location for VTune user files including data files associated with activities and activity results is the user home directory. It can be changed by using VTUNE_USER_DIR environment variable. If the variable is not set then the default location is $HOME/VTune in case you are using VTune in command line (vtl).

If you are using Eclipse* GUI (vtlec) then the following directories are also created $HOME/.eclipse and ECLIPSE_WORSKPACE (it is set during Eclipse startup). The default location for instrumented binaries and shared objects is "/tmp/vtune_$USER/Cache" directory. You can change it via "vtl global-options" by setting "cache-directory" set of parameters. For example "vtl global-options cache-directory=/new/cache/location/Cache". If you are using Eclipse GUI then you can change it for every Call Graph activity using Configure Call Graph Collectors » Advanced tab. The default location for symbol cache files is "/opt/intel/vtune/global-data/" directory. You can change it by setting VTUNE_GLOBAL_DIR environment variable.

Intel® VTune™ Performance Analyzer for Linux* - What is VTune™ VDK? Should I update it every time new VDK is released?

Fri, 19 Sep 2008 00:00:00 -0700

The VTune™ Analyzer Driver Kit is a package that is needed to do sampling profiling and build VTune sampling driver on Linux* for a non-supported version of Linux kernel. It consists of two parts: pre-compiled drivers for supported Linux distributions and source code of Linux kernel sampling driver. If you're installing VDK on one of unsupported Linux distributions you might need to recompile the driver to use sampling. To do that you also need development version of Linux kernel package or Linux kernel source package installed and configured properly. There are several versions of VDK.

Please check the Intel VDK site for the recent version of VDK package for your VTune version and more details. You only need to update VDK package in case Linux kernel was updated to the last released and installed VDK did not work with it. You can perform Call Graph profiling without loading sampling driver at all.