[Swift-commit] r3930 - text/parco10submission

[noreply at svn.ci.uchicago.edu]

Author: wozniak
Date: 2011-01-10 09:53:38 -0600 (Mon, 10 Jan 2011)
New Revision: 3930

Modified:
   text/parco10submission/paper.tex
Log:
First draft of performance test descriptions


Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2011-01-10 15:12:14 UTC (rev 3929)
+++ text/parco10submission/paper.tex	2011-01-10 15:53:38 UTC (rev 3930)
@@ -117,7 +117,7 @@
 However, others require the coupling or
 orchestration of large numbers of application invocations: either many
 invocations of the same program, or many invocations of sequences and
-patterns of several programs. 
+patterns of several programs.
 %In this model, existing applications are similar to
 %functions in programming, and users typically need to execute many of
 %them.
@@ -383,7 +383,7 @@
 in Section~\ref{mapping}) to files external to the Swift script.
 These files can then be read and written by application programs called by Swift.
 The mapping process can map single variables to single files, and structures and arrays to collections of files.
-There are no built-in mapped types in the language. Instead, users declare type names with no other structure to denote 
+There are no built-in mapped types in the language. Instead, users declare type names with no other structure to denote
 any mapped type names desired. For example: {\tt type file; type log;}
 
 A variable that is declared to be a mapped file
@@ -422,7 +422,7 @@
    }
 \end{verbatim}
 
-Structure fields can be of any type. 
+Structure fields can be of any type.
 Both types of collections can contain members of primitive, mapped, or collection types;
 in particular, arrays can be nested to provide multi-dimensional indexing.
 
@@ -435,18 +435,18 @@
    im = sn.i;
 \end{verbatim}
 
-Arrays contain values of only a single type; structure fields can be of any type. 
+Arrays contain values of only a single type; structure fields can be of any type.
 Both types of collections can contain members of primitive, mapped, or collection types.
 In particular, arrays can be nested to provide multi-dimensional indexing.
 
 The size of a Swift array is not declared in the program but is determined at run time, as items are added to the array.
 This feature proves useful for expressing some common classes of parallel computations. For example, we may
 create an array containing just those experimental configurations that satisfy a certain criteria.
-An array is considered ``closed'' when no further statements that set an element of the array can be executed. 
+An array is considered ``closed'' when no further statements that set an element of the array can be executed.
 This state is recognized at run time by information obtained from compile-time analysis of the script's call graph.
 %IAN: This last paragraph raises the issue of whether this state can always be determiend.
-The set of elements that is thus defined need not be contiguous; i.e., the index set may be sparse. 
-As we will see below, the {\tt foreach} 
+The set of elements that is thus defined need not be contiguous; i.e., the index set may be sparse.
+As we will see below, the {\tt foreach}
 statement makes it easy to access all elements of an array.
 
 %New types can be declared to define a new mapped type or to name a structure type. The type model is by design very simple and limited to keep type semantics easy to understand, implement and use.
@@ -820,7 +820,7 @@
 all files matching the name pattern \verb|*.jpeg| to an array--and then applies a function to each element of that array.
 
 Swift mappers can operate on files stored on the local machine in the directory where the {\tt swift} command is executing, or they can map any files accessible to the local machine, using absolute pathnames. Custom mappers (and some of the built-in mappers) can also map variables to files specified by URIs for access from remote servers via protocols such as GridFTP or HTTP, as described in section \ref{Execution}. Mappers can interact with structure fields and array elements in a simple and useful manner.
- 
+
 New mappers can be added to Swift either as Java classes or as simple, external executable scripts or programs coded in any language.
 Mappers can operate as both input mappers (which map files to be processed as application inputs) and as output mappers (which specify the names of files to be produced by applications). It is important to understood that mapping a variable is a different operation than setting the value of a variable. Variables of mapped-file type are mapped (conceptually) when the variable becomes``in scope'', but they are set when a statement assigns them a value. The invocation of mappers (including external executable mappers) are completely synchronized with the Swift parallel execution model.
 
@@ -1256,7 +1256,7 @@
 
 At lines 52-53, the script declares the array {\tt land} which will contain the output of the {\tt getlanduse} application. This declaration uses the built-in ``structured regular expression mapper'', which will determine the names of the \emph{output} files that the array will refer to once they are computed. Swift knows from context that this is an output mapping. The mapper will use regular expressions to base the names of the output files on the filenames of the corresponding elements of the input array {\tt geos} given by the {\tt source=} argument to the mapper. The declaration for {\tt land[]} maps, for example, a file {\tt h07v08.landuse.byfreq} to an element of the {\tt land[]} array for a file {\tt h07v08.tif} in the {\tt geos[]} array.
 
-At lines 55-57 the script performs its first computation using a {\tt foreach} loop to invoke {\tt getLandUse} in parallel on each file mapped to the elements of {\tt geos[]}. As 317 files were mapped (in lines 47-48), the loop will submit 317 instances of the application in parallel to the execution provider. These will execute with a degree of parallelism subject to available resources. 
+At lines 55-57 the script performs its first computation using a {\tt foreach} loop to invoke {\tt getLandUse} in parallel on each file mapped to the elements of {\tt geos[]}. As 317 files were mapped (in lines 47-48), the loop will submit 317 instances of the application in parallel to the execution provider. These will execute with a degree of parallelism subject to available resources.
 %\katznote{DONE: is this strictly true?  Do you want to say that it will enable 317 instances to be runnable in parallel, but the number that are actually run in parallel depends on the hardware available to Swift, or something like that?}
 At lines 52-53 the result of each computation is placed in a file mapped to the array {\tt land} and named by the regular expression translation based on the file names mapped to {\tt geos[]} .
 Thus the landuse histogram for file {\tt h00v08.tif} would be written into file {\tt h00v08.landuse.freq} and would be considered by Swift to be of type {\tt landuse}.
@@ -1309,12 +1309,12 @@
 these aspects to be encoded in the data files of the campaigns to assist in
 managing the large volume of file data.
 
-Hocky used four Swift scripts in his simulation campaign. The first, {\tt glassCreate} takes no input structure and generates an equilibrated configuration at some temperature; 
-{\tt glassAnneal} takes those structures and lowers the temperature to some specified temperature; 
+Hocky used four Swift scripts in his simulation campaign. The first, {\tt glassCreate} takes no input structure and generates an equilibrated configuration at some temperature;
+{\tt glassAnneal} takes those structures and lowers the temperature to some specified temperature;
 {\tt glassEquil} freezes particles outside of a spherical cavity and runs short simulations for particles inside; and the script {\tt glassRun}, described below, is the same but starts from equilibrated cavities.
 
 Example 2 shows a slightly reformatted version of the glass simulation script that was in use in Dec. 2010. Its key aspects are as follows.
-Lines 1-5 define the mapped file types; these files are used to compose input and output structures at lines 7-19. 
+Lines 1-5 define the mapped file types; these files are used to compose input and output structures at lines 7-19.
 These structure reflect the fact that the simulation is restartable in 1-2 hour increments, and that it works together with the Swift script to create a simple but powerful mechanism for managing checkpoint/restart across a long-running large-scale simulation campaign.
 
 The single application called by this script is the {\tt glassRun} program wrapped in the app function at lines 21-29. Note that rather than defining main program logic in ``open" (top-level) code, the script places all the program logic in the function {\tt CreateGlassSystem}, invoked by the single statement at line 80.  This enables the simulation script to be defined in a library that can be imported into other Swift scripts to perform entire campaigns or campaign subsets.
@@ -1342,26 +1342,76 @@
 \section{Performance Characteristics}
 \label{Performance}
 
-We present here a few additional measurements to supplement those previously published.
+We present here a few additional measurements to supplement
+those previously published.
 
+First, we measure the ability of Swift to support many user tasks on a
+single system image.  In Test A, we used Swift to submit up to 2,000
+tasks to Thwomp, a 16-core x86-based Linux compute server at Argonne
+National Laboratory.  Each job in the batch was an identical, simple
+single-processor job that executed for the given duration and
+performed application input and output at 1 byte each.  The total
+execution time was measured.  This was compared to the total amount of
+core-time consumed to report a utilization ratio, which is plotted.
+
+Second, we measure the ability of Swift to support many tasks on a
+large, distributed memory system without considering the effect on the
+underlying file services.  In Test B, we used Swift/Coasters to submit
+up to 20,480 tasks to Intrepid, the 40,000-node IBM BlueGene/P system
+at Argonne National Laboratory.  Each job in the batch was an
+identical, simple single-processor job that executed for the given
+duration and performed no I/O.  Each node was limited to one
+concurrent job, thus, the user task had 4 cores at its disposal.  The
+total execution time was measured.  This was compared to the total
+amount of node-time consumed to report a utilization ratio, which is
+plotted.
+
+Third, we measure the ability of Swift to support many tasks on a
+large, distributed memory system including application use of the
+underlying GPFS filesystem.  In Test C, we used Swift/Coasters to
+submit up to 10,240 tasks to Intrepid.  Each job in the batch was an
+identical, simple single-processor job that executed for 30 seconds
+and performed the given amount of input and output.  Coasters provider
+staging was used to distribute application data to workers, except in
+the case marked ``direct'', in which case the I/O was performed
+directly to GPFS.  Each node was limited to one concurrent job, thus,
+the user task had 4 cores at its disposal.  The total execution time
+was measured.  This was compared to the total amount of time consumed
+by an equivalent shell script-based application to report an
+efficiency ratio, which is plotted.
+
+The Test C shell script was provided with all job specifications in
+advance and did not require communication from between the worker
+nodes and the Swift/Coasters runtime.  Thus, this test measures the
+overhead involved in the dynamic job creation and scheduling
+functionality offered by Swift.
+
 \newcommand{\plotscale}{0.60}
 
 \begin{figure}
   \begin{center}
   {\footnotesize
     \begin{tabular}{p{7cm}p{7cm}}
-      \includegraphics[scale=\plotscale]{plots/sleep} &
-      \includegraphics[scale=\plotscale]{plots/multicore} \\
-      A. Application CPU utilization for 3 task durations  (in seconds) at up to 2,048 nodes of the Blue Gene/P.
-      at varying system size. \mikenote{What is efficiency here???}&
-      B. Application CPU utilization for 3 shorter task durations (in seconds) with up to 200 concurrent processes on an 8-core local host. \mikenote{What is efficiency here??? what host and how many cores?}\\
+     \includegraphics[scale=\plotscale]{plots/multicore} &
+     \includegraphics[scale=\plotscale]{plots/sleep} \\
+      Test A.
+      Application CPU utilization for 3 task durations
+      (in seconds) with up to 200 concurrent processes on an 8-core
+      local host. &
+      Test B.
+      Application CPU utilization for 3 task durations
+      (in seconds) at up to 2,048 nodes of the Blue Gene/P.
+      at varying system size. \\
       \includegraphics[scale=\plotscale]{plots/dds}
       & \\
-      C. Efficiency for a fixed number of tasks with varying data sizes. Input and out data was one file in each direction of the size indicated. Data transfer was done with direct transfer using Swift's collective data management interface \cite{SwiftCDM_2011}.
+      Test C.
+      Efficiency for a fixed number of tasks with varying data sizes.
+      Input and out data was one file in each direction of the size
+      indicated.
       & \\
     \end{tabular}
-    }
-    \caption{Swift performance metrics. Measures A and C were performed on the Blue Gene/P at various }
+  }
+    \caption{Swift performance figures.}
   \end{center}
 \end{figure}