A single configuration file can contain an arbitrary number of filter directives that are evaluated whenever a state is defined. Since they are evaluated in the same order as specified in the configuration file, the last filter matching a state determines whether it is traced or not. This scheme makes it easily possible to focus on a small set of activities without having to specify complex matching patterns. Being able to turn entire activities (groups of states) on or off helps to limit the number of filter directives.
Intel® Trace Collector for MPI applications produces tracefiles that can be analyzed with Intel® Trace Analyzer performance analysis tool. Some Intel® Trace Collector versions are also able to trace non-MPI applications, like socket communication in distributed applications or plain serial programs. It was formerly known as Vampirtrace*.
Normally if an MPI application fails or is aborted, all trace data collected so far is lost: libVT needs a working MPI to write the trace file, but the MPI standard does not guarantee that MPI is still operational after a failure. In practice most MPI implementations just abort the application. To solve this problem, link the application against libVTfs instead of libVT, like this:
--executable <file pattern>
Specifies the executable into which the Intel Trace Collector library is to be inserted. When analyzing MPI applications, the default is to pick the first executable which contains MPI calls. Otherwise, the first executable invoked by the command line is instrumented.
On Linux* OS, the Intel® Trace Collector can sample Operating System values for each process with the getrusage() system call and hardware counters with the Performance Application Programming Interface (PAPI). Because PAPI and getrusage() might not be available on a system, support for both is provided as an additional layer on top of the normal Intel® Trace Collector.
The application has to bootstrap the communication between the VTserver and its clients. This is done as follows:
The application server initiates its processes.
Each process calls VT_clientinit().
VT_clientinit() allocates a port for TCP/IP communication with the VTserver or other clients and generates a string which identifies the machine and this port.
This is a shortcut for --logfile-name - and --logfile-format ASCII, that is, it prints the trace data to stdout.
Setting this option to on lets stftool interpret all timestamps as ticks (rather than seconds, milliseconds and so on). Given time values are converted into seconds and then truncated (floor).