This video demonstrates
the difference among several
Intel instrumentation and tracing
technology APIs,
or ITT APIs,
including the use of process based
frame APIs
compared to the thread
based event and task APIs.
While code instrumentation
is optional for VTune Profiler
analysis, instrumented
code can provide enhanced insights
into algorithm performance.
Examples with use cases
that can benefit from instrumentation
include analyzing applications
performing repeated calculations,
or analyzing
transaction processing
on a per transaction
basis to discover
the cases that experienced
bad performance.
Frames represent
a series of non-overlapping
regions of elapsed time
between frame begin and end points.
When frames are displayed
in Intel VTuneProfiler
they are displayed in a separate track
so they provide
a way to visually separate
this data from normal task data.
Frames are per process
and not associated
with any specific thread.
The event
API is used to observe when events occur
in your application
or to identify
how long it takes
to execute regions of code.
A task is a logical unit of work
performed by a particular thread
for a period of time.
Tasks typically correspond
to functions, scopes
or a case block in a switch statement.
First, let's look at the source code
implementing these ITT APIs.
This is the resource definition
and initialization
of the domain and events
and task strings.
Notice that there is no naming
for the frame APIs.
Also, to help distinguish
these later,
the event names in this example
start with calculate
and the task names do not.
The task is defined
by the bracketing of ITT
task begin
and ITT task
end calls on the same thread.
The events and tasks can be used to mark
any block of code.
In this example,
they are used
as function
wrappers to mark the beginning
and end of the function.
When event APIs
are used with matching events
start and event
end calls,
results are displayed similar
to task API calls.
When only calling events
start
without a matching event and a tick
mark is displayed in the timeline view.
This example shows
the matching events start
and event end call behavior.
Another difference
between using events and tasks
is that tasks are associated
with a specific ITT domain,
while an event is not.
The frame begin and frame end APIs
can also mark
the beginning
and end of a code block
and are associated with an ITT domain.
In this example,
it is before
and after two calls to the calculation
function.
Consecutive frame
begin calls in the same
domain are treated
as a frame end,
followed by a frame begin pair.
To demonstrate
the difference
between thread specific
APIs and processwide APIs,
this example first executes
for-calculation sequentially,
then executes the for-calculations
in parallel using P threads.
Configure Intel VTune Profiler
to run a collection similar
to how you normally would.
Specify the local or remote host
the application and the analysis type.
When the data collection completes,
the summary tab is activated.
This includes
the usual summary statistics
and top hotspots at the top,
CPU utilization
histogram in the middle,
and the platform
information at the bottom.
It also includes
a table of top
tasks and events
by count and execution time
and a frame rate histogram
showing the duration of the frames
with the count of fast
and slow frames relative to each other.
This histogram shows
five slow frames and three fast frames.
The timeline display
in the bottom up tab shows
the beginning
and end of the events
and tasks per thread.
Most hover over those markers
to see the event
or task name, start time and duration.
Frames are displayed
in a dedicated timeline track.
Most hover over the frame markers
to see the count,
start time, duration, and fast
slow assessment.
In this example,
when the child threads execute
serially, the frame
count increases gradually.
When the three child threads
execute simultaneously,
the frame begin was called
four times in rapid succession.
Consecutive frame
begins are treated as a frame end
followed by a frame begin,
so the frame count
rapidly increases from 4 to 8.
This is where VTune calculated
the three fast frames
and rated the others as slow.
We can zoom in on the timeline view
to better see this behavior.
Changing the grouping
to task
the main task
type shows some additional differences
among these APIs.
First metrics for frames
are not displayed in this view.
Also, observe
that the tasks are associated
with the domain specified
in the application,
but the events are system wide.
We have the option to filter
in on any of the tasks or events,
change the grouping to frame demand
frame, duration
type frame
to see the frames
ordered by execution time.
Right click on a frame
in this list and select filter
in by selection
to see the relevant metrics and timeline
information for this frame
that makes it easier to identify
where to select a timeline
range to zoom in.
In this case, four
threads were executing simultaneously,
which causes the longest frame duration.