SSCORD(1) SSCORD(1)
sscord - explore working set behavior and generate cord feedback files
sscord [-fb <feedback-file-name>] [-wsl <ws-list-file>] [-ws <analysis>]
[-v|-V] [-scheme schemeName] executable
sscord is a tool designed to allow a user to explore the working set
behavior of an executable or shared library (DSO), and to construct a
feedback file for use by cord to generate an executable with improved
working-set behavior.
sscord reads the executable or DSO given by executable, and generates a
function list from it. It can import individual working-sets or the sets
named in a working-set-list file; it can also import an existing order
(feedback file). It shows the list of working sets, and a page map for a
selected working set, and allows for operations to construct union or
intersection combinations of existing sets, to construct either of two
cord orderings, or to save a working-set-list file.
The premise for this tool is as follows: when application and/or DSOs
execute, they bring in pages from their instructions (text) as needed to
execute the chain of functions triggered by any operation. By running a
SpeedShop Performance Experiment, and capturing ideal-time data either
for samples that demarcate specific operations of the target, or periodic
samples, the user can generate working-set files, each listing all the
functions that were executed for the operation whose beginning and end
are delineated by the caliper setting, or which were executed during each
periodic interval. From that information, and improved ordering for the
functions is generated as a feedback file to be used as input to cord(1)
(or, in the near-term future, to ld(1)).
In order to construct a cording, the user first runs one or more idealtime
experiments (either SpeedShop or WorkShop) for the executable or
DSO, taking samples at appropriate points to demarcate the desired
operations. The more carefully the sample points are chosen for
important operations, and the more complete the set of defined operations
for which data is collected, the better the ordering should be. Even if
no samples are taken, a reordering that will group executed functions
together and unexecuted function together may still improve performance.
From one or more such experiments, the user then extracts various
working-set files, written in response to the -ws or -wsall command-line
flags in prof, for SpeedShop experiments, or with a menu operation on the
Working Set View of cvperf for WorkShop experiments. A script, sswsextr,
may be used to automatically extract working set files for all pairs of
consecutive caliper-points, from a SpeedShop ideal-time experiment; it
generates all the files referred to below.
Page 1
SSCORD(1) SSCORD(1)
Working-set files may be generated using different versions of the
executable or DSO; they may also be generated from different a.out's
using the DSO being ordered. (One assumption of this method is that
while program versions may change, the list of functions for an operation
changes much less frequently.) Any mismatches between the working-set
and the actual executable/DSO are noted if the verbose flag is set, but
otherwise ignored.
sscord is then invoked, giving it the executable or DSO name, and
optionally, a working-set file, or a working-set-list-file, listing a set
of such files, with one line per working-set file. Using sscord,
additional files or sets of files may be imported, and the user can
generate additional working-set files as unions or intersections of
selected groups of existing sets. The strategy for deciding which such
combinations to make, and why is based on the following. Unions are
typically used when cord'ing libraries; they are generated when there are
a number of different working sets that cover what is believed to be
similar functionality. The union set is generated, and given higher
priority than any of the individual component working sets.
Intersections are much less frequently used; the most common case where
an intersection might be useful is to ensure that functionality common to
two or more working sets is represented as such. The intersection set is
generated, and then given higher priority than the components that went
into it.
Eventually, the sscord user-interface will allow manual rearrangement of
the list; for now, it does not, and the user should invoke the ``Save
Working Set List'' menu item of sscord to save a new list with the
additional union or intersection sets included. Then, exit sscord, and
edit the list by hand in order to have the working-sets in the list in
priority order. The list of working sets should be prioritized from
bottom to top, with the least important set appearing first, and the most
important set appearing last.
The criteria for prioritization is quite subjective. If you want the
initial startup of your program to be fast, giving the appearance of
rapid response, put the working set for the startup as the bottom entry
in the list, and then order the others from least-important operation to
most-important.
When the ordered working-set list file is ready, the user reinvokes
sscord with the same executable and cord mapping, and the newly
prioritized working-set-list. The user then invokes the ``Construct
Gray-code Cording Feedback'' or the ``Construct Weighted Cording
Feedback'' menu items to generate a new cord feedback file, which is then
used directly by cord to rearrange the executable or DSO.
Gray-code ordering is used to generate an ordering to minimize the
working-sets for the highest-priority set first, and then ordering it to
minimize the transitions between the first set and the second, then
compacting the second, and minimizing the transitions between it and the
third, and so forth. Gray-code is believed to be superior to weighted
Page 2
SSCORD(1) SSCORD(1)
ordering, but the user might want to experiment with them both.
Weighted ordering attempts to find as many distinct affinity-sets as it
can, and to order them to minimize the working sets for them operations
in a weighted priority order.
During these operations, the sscord may be used to examine the page
layout and efficiency of each working-set with respect to the original
cording, a newly constructed cording, or an alternate cord feedback file
that can be read in to replace the current one. The interface is
described below.
sscord accepts the following command-line options:
<executable>
is the last command-line argument, and specifies the executable or
DSO whose behavior is being explored.
-fb feedback
specifies a single text file to use as a feedback file for the
executable. If no -fb argument is given, the ordering will be the
order derived from the executable/DSO's symbol table. For o32, the
order will be as previously corded; for n32, the order will be precording.
-wsl fileset
specifies a single text file name as input; the working set list
will consist of the working-set files whose names appear in the
input file. Each file name should be on a single line.
-ws file
specifies a single working-set file name.
-scheme schemeName
specifies which color scheme should be used for sscord.
-v | -V
specifies that verbose output should be generated; if set,
mismatches between working sets and the executable or DSO will be
noted.
sscord uses many resources to control its user interface, most of which
should not be changed by the user. Those that a user might want to
change are:
sscord*pageSize
specifies the size of pages to be used for sscord's computations.
It defaults to the page size on the machine on which it is running.
Page 3
SSCORD(1) SSCORD(1)
sscord*scheme
specifies the color and font scheme to be used for sscord.
sscord*useSmallFonts
specifies that small fonts are to be used for sscord in order to
better use screen real-estate. It defaults to False.
sscord initially comes up with a menu bar, a status area, a working-set
list pane, a control region, and a working-set page map pane. It has an
additional window that may be invoked, the function list window.
MENU BAR
The ``Admin'' menu has entries to save a summary of the data for the
current working set list, to iconify or raise the windows of the Cord
Analyzer View, or to exit the tool. It also has a ``Launch Tool''
submenu that will launch the other WorkShop tools, and a ``Project'' menu
that will raise or iconify all windows in all tools within the project,
or exit all tools in the project.
The ``File'' menu allows the user to add or delete working sets from the
list; to construct a cording order from the working sets; and to
construct a union and/or intersection set from the sets that are selected
at the time the menu item is selected; and to replace the current cord
ordering with one read from a feedback file.
The ``Help'' menu is used to access on-line help for sscord.
THE STATUS AREA [Toc] [Back]
The status area is used to inform the user of the current status of the
program, as well as to describe any performance experiment that is in the
current project.
THE WORKING SET LIST [Toc] [Back]
The upper subpane in the main window is the Working Set List. It
contains a scrolled list of all the working sets in the files belonging
to the set, with information about the page count computed with the
current ordering, and minimum page count for each working set. In
addition, if a function is selected, a + sign at the beginning of the
line indicates that the selected function is used in the set.
A set may be selected by double-clicking on the line in the Working Set
List showing that set. The ``Next Set'' and ``Previous Set'' buttons may
be used to step forwards and backwards through the list. If no loop is
selected, the ``Next Set'' and ``Previous Set'' buttons will select the
first set on the list. The selected set will be used to mark those
functions in the Function List Window that were referenced in the
working-set.
THE CONTROL AREA [Toc] [Back]
Page 4
SSCORD(1) SSCORD(1)
The control area contains a search field to find a set based on any
string appearing in its line, and a row of buttons. The search field is
on the left side of the control area. Three buttons appear on the right:
one to invoke the function list, and two buttons to step forwards and
backwards through the working-set list.
THE WORKING SET PAGE MAP PANE
The lower subpane of the main window is the Working Set Page Map Pane.
It has several information lines, below which is a colored map of the
pages in the executable. The information lines show detailed information
for the selected set from the Loop List, and any selected page.
The block area for each page in the executable or DSO, is colored to
represent the fraction of instructions on that page belonging to
functions that were executed within the selected working-set (dark blue),
the fraction of instructions belonging to functions that were not
executed (red), and the fraction of word that either contain table-data
or represent the tail-end of the last page (bright blue). If any page
has no executed functions on it, it is shown in green. A page may be
selected by clicking on it; it will be drawn with a heavy outline, and
statistics about it will be shown above the map.
THE FUNCTION LIST WINDOW
The Funtion List Window is brought up by the ``Show Function List''
button. It consists of a scrolled list of all the functions contained in
the executable or DSO, in the order given by the last cord feedback file
read in or generated. Each function is shown with a count of the number
of working-sets in which it appears, its size, its address, and its name.
If the function is used within the current selected set, a + sign will
appear at the beginning of its line. It also has a field for entering or
modifying a weight for each working set; this weight is used only for
weighted feedback generation.
Double clicking on a line in this view will select the function, and set
the indicators for the function's use on the working-set list.
speedshop(1), cvperf(1), prof(1), cord(1), ssorder(1), sswsextr(1)
No method is available for reordering the working-sets through the UI.
No method is available to hand-order the functions to produce a feedback
file.
PPPPaaaaggggeeee 5555 [ Back ]
|
