*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> sscord (1)              


SSCORD(1)							     SSCORD(1)

NAME    [Toc]    [Back]

     sscord - explore working set behavior and generate	cord feedback files

SYNOPSIS    [Toc]    [Back]

     sscord [-fb <feedback-file-name>] [-wsl <ws-list-file>] [-ws <analysis>]
     [-v|-V] [-scheme schemeName] executable

DESCRIPTION    [Toc]    [Back]

     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.

METHODOLOGY    [Toc]    [Back]

     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

     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:

	  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

X RESOURCES    [Toc]    [Back]

     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:

	  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)

	  specifies the	color and font scheme to be used for sscord.

	  specifies that small fonts are to be used for	sscord in order	to
	  better use screen real-estate.  It defaults to False.

USER INTERFACE    [Toc]    [Back]

     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.

     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

   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 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 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.

SEE ALSO    [Toc]    [Back]

     speedshop(1), cvperf(1), prof(1), cord(1),	ssorder(1), sswsextr(1)

BUGS    [Toc]    [Back]

     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

									PPPPaaaaggggeeee 5555
[ Back ]
 Similar pages
Name OS Title
ssorder IRIX compute and write cord feedback files from working set data
thrash IRIX thrash memory to explore paging behavior
feedback Tru64 Generate an optimization feedback file using pixie and prof
fbdump IRIX print out compiler feedback files from prof
rcsclean IRIX clean up working files
rcsclean FreeBSD clean up working files
rcsclean Tru64 clean up working files
rcsclean OpenBSD clean up working files
sswsextr IRIX extract working set files from SpeedShop ideal-time experiment
ftoc Tru64 interface between prof and cord
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service