[Swift-commit] r3373 - text/parco10submission
noreply at svn.ci.uchicago.edu
noreply at svn.ci.uchicago.edu
Tue Jun 15 21:37:05 CDT 2010
Author: wozniak
Date: 2010-06-15 21:37:05 -0500 (Tue, 15 Jun 2010)
New Revision: 3373
Modified:
text/parco10submission/paper.tex
Log:
Misc fixes after read-through
Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex 2010-06-16 01:27:29 UTC (rev 3372)
+++ text/parco10submission/paper.tex 2010-06-16 02:37:05 UTC (rev 3373)
@@ -16,7 +16,7 @@
% draft - contact benc at ci.uchicago.edu
-% ACM styleguide says max 3 ayuthors here, rest in acknowledgements
+% ACM styleguide says max 3 authors here, rest in acknowledgements
%% \numberofauthors{4}
@@ -30,8 +30,6 @@
%% \alignauthor Mihael Hategan \\
%% \affaddr{University of Chicago Computation Institute}\\
%% \and
-%% \alignauthor Sarah Kenny \\
-%% \affaddr{University of Chicago Computation Institute}\\
%% \alignauthor Michael Wilde \\
%% \affaddr{University of Chicago Computation Institute}\\
%% \affaddr{Argonne National Laboratory} \\
@@ -40,7 +38,6 @@
\author{Ben Clifford}
\author{Ian Foster}
\author{Mihael Hategan}
-\author{Sarah Kenny}
\author{Justin M. Wozniak}
\author{Michael Wilde}
@@ -50,16 +47,15 @@
Scientists, engineers and business analysts often work by performing a
massive number of runs of domain-specific programs, typically coupled
-loosely by large collections of file-based data. Distributed and
+loosely by large collections of file-based data. Distributed and
parallel computing resources provide a powerful way to get more of
this type of work done faster, but using such resources imposes
additional complexities. Swift reduces these complexities with a
scripting language for composing ordinary application programs (serial
or parallel) into more powerful parallel applications that can be
executed on distributed resources. We present the language, details of
-the implementation, application examples, measurements, and ongoing
-research, focusing on its importance as a distributed computing
-paradigm.
+the implementation, application examples, and ongoing research,
+focusing on its importance as a distributed computing paradigm.
\end{abstract}
@@ -75,23 +71,23 @@
application programs (serial or parallel) into distributed,
parallelized applications for execution on grids and supercomputers
with tens to hundreds of thousands of processors. It is intended to
-serve as a higher level framework for composing parallel pipelines of
-other programs and scripts, sitting above (and utilizing) existing
-scripting languages and applications. Swift scripts express the
-execution of programs to produce datasets using a dataflow-driven
-specification. The application programs executed by a Swift script can
-be binary executables or can be scripts written in any other scripting
-language.
+serve as a higher level framework for composing the interaction of
+concurrently executing programs and scripts, sitting above (and
+utilizing) existing scripting languages and applications. Swift
+scripts express the execution of programs to produce datasets using a
+dataflow-driven specification. The application programs executed by a
+Swift script can be binary executables or can be scripts written in
+any other scripting language.
Swift's contribution and primary value is that it provides a simple,
minimal set of language constructs to specifiy how applications are
glued together at large scale in a simple compact form, while keeping
the language simple and elegant, and minimizing any overlap with the
tasks that existing scripting langauges do well. Swift regularizes and
-abstracts both the notion of data and process for distributed parallel
-execution of application programs. Applications expressed in Swift
-are location-independent and automatically parallelized by exploiting
-available concurrency in the given dataflow .
+abstracts notions of external data and processes for distributed
+parallel execution of application programs. Applications expressed in
+Swift are location-independent and automatically parallelized by
+exploiting available concurrency in the given dataflow.
Swift can execute scripts that perform tens of thousands of program
invocations on highly parallel resources, and handle the unreliable
@@ -108,7 +104,7 @@
its implementation handles large-scale and distributed execution
environments, and its contribution to distributed and parallel computing.
-\subsection{Rationale}
+\subsection*{Rationale}
The emergence of large-scale production computing infrastructure such
as clusters, grids and high-performance computing (HPC), and the
@@ -120,28 +116,28 @@
large scale.
While many application needs involve the execution of a single large
-and perhaps message-passing parallel app, many others require the
-coupling or orchestration of large numbers of application invocations:
-either many invocations of the same app, or many invocations of
-sequences and patterns of several apps. In this model, existing apps
-become like functions in programming, and users typically need to
-execute many of them. Scaling up requires the distribution of such
-workloads among many computers (``resources''), and hence a ``grid''
-approach. Even if a single large parallel resource suffices, users
-won't always have access to the same supercomputer cluster: hence the
-need to utilize whatever resource happened to be available or
-economical at the moment when they need to perform intensive
-computation - without continued reprogramming or adjustment of scripts.
+message-passing parallel program, many 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. In this model, existing apps become like
+functions in programming, and users typically need to execute many of
+them. Scaling up requires the distribution of such workloads among
+many computers (``resources''), and hence a ``grid'' approach. Even if
+a single large parallel resource suffices, users will not always have
+access to the same supercomputer cluster: hence the need to utilize
+whatever resource happened to be available or economical at the moment
+when they need to perform intensive computation - without continued
+reprogramming or adjustment of scripts.
We claim that the missing feature in current scripting languages is
sufficient specification and encapsulation of inputs to, and outputs
from, a given application, such that an execution environment could
automatically make remote execution transparent. Without this,
achieving location transparancy and automated parallel execution is
-not feasible. Swift adds to scripting what RPC adds to programming:
-by formalizing the inputs and outputs of
-``applications-as-procedures'', it provides a way to make the remote -
-and hence parallel - execution of applications fairly transparent.
+not feasible. Swift adds to scripting what remote procedure calls
+(RPC) add to programming: by formalizing the inputs and outputs of
+applications-as-procedures, it provides a way to make the remote
+execution of applications fairly transparent.
The remainder of this paper is organized as follows. In
Section~\ref{Language} we present the major concepts and language
@@ -161,20 +157,21 @@
invocation of ``ordinary programs'' - technically, POSIX {\tt exec()}
operations - in a manner that explicitly specifies the files and other
arguments that are the inputs and outputs of each program
-invocation. This formal but simple model (elaborated in section
-\ref{LanguageEnvironment}) enables Swift to provide several critical
-features not provided by - nor readily implemented in - existing
-scripting languages like Perl, Python, or shells:
+invocation. This formal but simple model enables Swift to provide
+several critical characteristics not provided by - nor readily
+implemented in - existing scripting languages like Perl, Python, or
+shells. Notable features include:
\begin{itemize}
\item Location transparent execution: automatically selecting a
-location for each program invocation and managing diverse execution
-environments. Swift scripts can be tested on a single local
-workstation. The same script can then be executed on a cluster, one or
-more grids of clusters, and on large scale parallel supercomputers
-such as the Sun Constellation~\cite{SunConstellation_2008}
-or the IBM Blue Gene/P~\cite{BGP_2008}. Notable features include:
+ location for each program invocation and managing diverse execution
+ environments. Swift scripts can be tested on a single local
+ workstation. The same script can then be executed on a cluster, one
+ or more grids of clusters, and on large scale parallel
+ supercomputers such as the Sun
+ Constellation~\cite{SunConstellation_2008} or the IBM Blue
+ Gene/P~\cite{BGP_2008}.
\item Automatic parallelization of program invocations, invoking
programs that have no data dependencies in parallel;
@@ -280,7 +277,7 @@
rotated = rotate(photo, 180);
\end{verbatim}
-While this looks like an assignment, the actual unix level execution
+While this looks like an assignment, the actual level execution
consists of invoking the command line specified in the \verb|app|
declaration, with variables on the left of the assignment bound to the
output parameters, and variables to the right of the procedure
@@ -337,7 +334,7 @@
can be mapped to a collection of files, one element per file, by using
a different form of mapping expression. For example, the
\verb|filesys_mapper| maps
-all files matching a particular unix glob pattern into an array:
+all files matching a particular glob pattern into an array:
\begin{verbatim}
file frames[] <filesys_mapper; pattern="*.jpeg">;
@@ -345,7 +342,6 @@
The \verb|foreach| construct can be used to apply the same procedure
call(s) to each element of an array:
-
\begin{verbatim}
foreach f,ix in frames {
output[ix] = rotate(frames, 180);
@@ -353,14 +349,12 @@
\end{verbatim}
Sequential iteration can be expressed using the \verb|iterate| construct:
-
\begin{verbatim}
step[0] = initialCondition();
iterate ix {
step[ix] = simulate(step[ix-1]);
}
\end{verbatim}
-
This fragment will initialise the 0-th element of the \verb|step| array
to some initial condition, and then repeatedly run the \verb|simulate|
procedure, using each execution's outputs as input to the next step.
@@ -373,7 +367,7 @@
parameters have been assigned values. As a result of such execution,
more variables may become assigned, possibly allowing further parts of
the script to execute. In this way, scripts are implicitly
-concurrent. Aside from serialisation implied by these dataflow
+concurrent. Aside from serialization implied by these dataflow
dependencies, execution of component programs can proceed without
synchronization in time.
@@ -390,17 +384,16 @@
z=q(y);
\end{verbatim}
-Arrays in SwiftScript are more generally
-\emph{monotonic}\cite{MONOTONICPHD}; that is, knowledge about the
-content of an array increases during execution, but cannot otherwise
-change. Once a value for a particular element is known, then it cannot
-change. Eventually, all values for an array are known, and that array
-is regarded as \emph{closed}. Statements which deal with the array as
-a whole will wait for the array to be closed before executing (thus, a
-closed array is the equivalent of a non-array type being
-assigned). However, a \verb|foreach| statement will apply its body to
-elements of an array as they become known. It will not wait until the
-array is closed.
+Arrays in SwiftScript are more generally \emph{monotonic}, that is,
+knowledge about the content of an array increases during execution,
+but cannot otherwise change. Once a value for a particular element is
+known, then it cannot change. Eventually, all values for an array are
+known, and that array is regarded as \emph{closed}. Statements which
+deal with the array as a whole will wait for the array to be closed
+before executing (thus, a closed array is the equivalent of a
+non-array type being assigned). However, a \verb|foreach| statement
+will apply its body to elements of an array as they become known. It
+will not wait until the array is closed.
Consider the script below:
\begin{verbatim}
@@ -444,7 +437,7 @@
\end{verbatim}
Ordering of execution is generally determined by execution of \verb|app|
-procedures, not by any containing procedures. In this code block:
+procedures, not by any containing procedures. In this script segment:
\begin{verbatim}
(file a, file b) A() {
a = A1();
@@ -545,7 +538,7 @@
\subsection{Swift mappers}
-The Swift programmer manipulate in-memory variables which are
+The Swift programmer manipulates in-memory variables which are
\emph{mapped} to files in the filesystem. This is coordinated by an
extensible set of components called \emph{mappers}. Swift contains a
number of built-in mappers. A representative sample of these is listed
@@ -627,13 +620,11 @@
dependency), or that their working directories will or will not be
cleaned up after execution.
-Consider the \verb|app| declaration for the \verb|rotate| procedure in
-section N:
-
+Consider the following \verb|app| declaration for the \verb|rotate|
+procedure:
\begin{verbatim}
app (file output) rotate(file input, int angle)
\end{verbatim}
-
The procedure signature declares the inputs and outputs for this
procedure. As in many other programming languages, this defines the
type signatures and names of parameters; this also defines which files
@@ -649,19 +640,19 @@
convert "-rotate" angle @input @output;
\end{verbatim}
-The body of the \verb|app| block defines the unix command-line that
-will be executed when this procedure is invoked. The first token (in
-this case \verb|convert|) defines a \emph{transformation name} which
-is used to determine the unix executable name. Subsequent expressions,
-separated by spaces, define the command-line arguments for that
-executable: \verb|"-rotate"| is a string literal; angle specifies the
-value of the angle parameter; the syntax \verb|@variable| evaluates to
-the filename of the supplied variable, thus \verb|@input| and
-\verb|@output| evaluate to the filenames of the corresponding
-parameters. It should be noted that it is possible to take the
-filename of \verb|output| even though it is a return parameter;
-although the value of that variable has not yet been computed, the
-filename where that value will go is already known.
+The body of the \verb|app| block defines the command-line that will be
+executed when this procedure is invoked. The first token (in this case
+\verb|convert|) defines a \emph{transformation name} which is used to
+determine the executable name. Subsequent expressions, separated by
+spaces, define the command-line arguments for that executable:
+\verb|"-rotate"| is a string literal; angle specifies the value of the
+angle parameter; the syntax \verb|@variable| evaluates to the filename
+of the supplied variable, thus \verb|@input| and \verb|@output|
+evaluate to the filenames of the corresponding parameters. It should
+be noted that it is possible to take the filename of \verb|output|
+even though it is a return parameter; although the value of that
+variable has not yet been computed, the filename where that value will
+go is already available from the mapper.
\section{Execution}
\label{Execution}
@@ -669,14 +660,12 @@
Swift is implemented by compiling to a Karajan program, which provides
several benefits. A notable benefit visible to users is that of
providers. This enables the Swift execution model to be extended by
-adding new data providers and job execution providers. This is
-explained in more detail in section \ref{ExecutingSites}: Executing on
-a remote site.
+adding new data providers and job execution providers.
\subsection{Executing on a remote site}
\label{ExecutingSites}
-With the above restrictions, execution of a unix program on a remote
+With the above restrictions, execution of a program on a remote
site is straightforward. The Swift runtime must prepare a remote
working directory for each job with appropriate input files staged in;
then it must execute the program; and then it must stage the output
@@ -698,7 +687,7 @@
\emph{file access provider}.
Two common implementations of this model are execution on the local
-system; and execution on one or more remote sites in a grid managed by
+system, and execution on one or more remote sites in a grid managed by
Globus~\cite{Globus_Metacomputing_1997} software. In the former case,
a local scratch file system (such as {\tt /var/tmp}) may be used as
the accessible file system; execution of programs is achieved by
@@ -760,12 +749,12 @@
\emph{restarts} and \emph{replication}.
In the simplest form of error handling in Swift, if a component
-program fails then Swift will make a second (or subsequent) attempt to
-run the program. In contrast to many other systems, retry here is at
-the level of the SwiftScript procedure invocation, and includes
-completely reattempting site selection, stage in, execution and stage
-out. This provides a natural way to deal with many transient errors,
-such as temporary network loss, and with many changes in site state.
+program fails, Swift will make a subsequent attempt to run the
+program. In contrast to many other systems, retry here is at the level
+of the SwiftScript procedure invocation, and includes completely
+reattempting site selection, stage in, execution and stage out. This
+provides a natural way to deal with many transient errors, such as
+temporary network loss, and with many changes in site state.
Some errors are more permanent in nature; for example, a component
program may have a bug that causes it to always fail given a
@@ -810,15 +799,16 @@
component program executions are bound to worker jobs (and thus to worker
nodes) as those nodes become available.
-Clustering requires very little additional support on the remote site;
-coasters require an active component on the head node (in Java) and
-on the worker nodes (in PERL) as well as additional network connectivity.
-In practical usage, the automatic deployment and execution of these
-components is difficult on a number sites.
+Clustering requires very little additional support on the remote site.
+However, the coasters framework requires an active component on the
+head node (in Java) and on the worker nodes (in PERL) as well as
+additional network connectivity within a site. In practical usage, the
+automatic deployment and execution of these components can be
+difficult on a number sites.
-However, ahead-of-time clustering can be less efficient than using
-coasters. Coasters can react much more dynamically to changing numbers
-of available worker nodes. When clustering, some estimation of how
+However, clustering can be less efficient than using coasters.
+Coasters can react much more dynamically to changing numbers of
+available worker nodes. When clustering, some estimation of how
available remote node count and of job duration must be made to decide
on a sensible cluster size. Incorrectly estimating this can (in one
direction) result in an insufficient number of worker nodes being
@@ -828,11 +818,12 @@
execute is known, so can get more work done per GRAM job submission,
and get it done earlier.
-Job status for coasters is reported as jobs start and end; for clustered jobs,
-job completion status is only known at the end of the entire cluster. This
-means that subsequent activity (stageouts, and the beginning of dependant
-jobs) is delayed (in the worst case, activity dependant on the first job
-in a cluster must wait for all of the jobs to run).
+Job status for coasters is reported as jobs start and end; for
+clustered jobs, job completion status is only known at the end of the
+entire cluster. This means that subsequent activity (stageouts, and
+the beginning of dependant jobs) is delayed (in the worst case,
+activity dependant on the first job in a cluster must wait for all of
+the jobs to run).
\subsection{Features to support use on dynamic resources}
@@ -840,24 +831,24 @@
practical challenges that are not encountered when running on a small
number of sites. These challenges are seen when comparing execution on
the TeraGrid~\cite{TeraGrid_2005} with execution on the Open Science
-Grid (OSG)~\cite{OSG_2007}. The set of sites which may be used is large and
-changing. It is impractical to maintain a site catalog by hand in this
-situation. In collaboration with the OSG Engagement group, Swift was
-interfaced to ReSS\cite{ReSS_2007} so that the site catalog is
-generated from that information system. This provides a very
-straightforward way to generate a large catalog of sites that are
+Grid (OSG)~\cite{OSG_2007}. The set of sites which may be used is
+large and changing. It is impractical to maintain a site catalog by
+hand in this situation. In collaboration with the OSG Engagement
+group, Swift was interfaced to ReSS~\cite{ReSS_2007} so that the site
+catalog is generated from that information system. This provides a
+very straightforward way to generate a large catalog of sites that are
likely to work.
Having discovered those sites, two significant problems remain: the
quality of those sites varies wildly; and user applications are not
installed on those sites. Individual OSG sites exhibit extremely
different behaviour, both with respect to other sites at the same
-time, and with respect to themselves at other times. This is hard to
-describe statically. Firstly, the load that a particular site will
-bear varies over time. Secondly, some sites fail in unusual fashion.
-Swift's site scoring mechanism deals well with this in the majority of
-cases. However, continued discovery of unusual failure modes drives
-the implementation of ever more fault tolerance mechanisms.
+time, and with respect to themselves at other times. The load that a
+particular site will bear varies over time and some sites fail in an
+unusual manner. Swift's site scoring mechanism deals well with this in
+the majority of cases. However, continued discovery of unusual failure
+modes drives the implementation of ever additional fault tolerance
+mechanisms.
When running jobs on dynamically discovered sites, it is likely that
component programs are not installed on those sites. OSG Engagement
@@ -1121,116 +1112,6 @@
doall(p);
\end{verbatim}
-\section{Future work}
-\label{Future}
-
-Swift is an actively developed project. Current directions in Swift
-development focus on improvements for short-running tasks, massively
-parallel resources, data access mechanisms, site management, and
-provenance.
-
-\subsection{Provisioning for more granular applications}
-
-In some applications the execution time for a program is very
-short. In such circumstances, execution time can become dominated by
-GRAM and LRM overhead. A resource provisioning system such as
-Falkon~\cite{Falkon_2008} or the CoG~\cite{CoG_2001} coaster mechanism
-developed for Swift can be used to ameliorate this overhead, by
-incurring the allocation overhead once per worker node. Both of these
-mechanisms can be plugged into Swift straightforwardly through the CoG
-provider API.
-
-\subsection{Swift on thousands of cores}
-
-Systems such as the Sun Constellation~\cite{SunConstellation_2008} or
-IBM BlueGene/P~\cite{BGP_2008} have hundreds of thousands of cores,
-and systems with millions of cores are planned. Scheduling and
-managing tasks running at this scale is a challenging problem in
-itself and relies of the rapid submission of tasks as noted
-above. Swift applications currently do run on these systems by
-scheduling Coasters workers using the standard job submission
-techniques and employing an internal IP network.
-
-\subsection{Filesystem access optimizations}
-
-Similarly, some applications deal with files that are uncomfortably
-small for GridFTP (on the order of tens of bytes). For this, a
-lightweight file access mechanism provided by CoG Coasters can be
-substituted for GridFTP. When running on HPC resources, the thousands
-of small accesses to the filesystem may create a bottleneck. To
-approach this problem, we have investigated application needs and
-initiated a set of Collective Data Management (CDM)~\cite{CDM_2009}
-primitives to mitigate these problems.
-
-\subsection{Provenance}
-\label{Provenance}
-
-Swift produces log information regarding the provenance of its output files.
-In an existing development module, this information can be imported
-into relational and XML databases for later querying. Providing an
-efficient query mechanism for such provenance data is an area of
-ongoing research; whilst many queries can be easily answered
-efficiently by a suitably indexed relational or XML database, the lack
-of support for efficient transitive queries can make some common
-queries involving either transitivity over time (such as 'find all
-data derived from input file X') or over dataset containment (such as
-'find all procedures which took an input containing the file F')
-expensive to evaluate and awkward to express.
-
-%% \subsection{GUI workflow design tools}
-
-%% In contrast to a text-oriented programming language like SwiftScript,
-%% some scientists prefer to design simple programs using GUI design tools.
-%% An example of this is the LONI Pipeline tool\cite{LONIPIPELINE}. Preliminary
-%% investigations suggest that scientific workflows designed with that tool
-%% can be straightforwardly compiled into SwiftScript and thus benefit from
-%% Swift's execution system.
-
-%% \subsection{Site selection research}
-
-%% TODO: data affinity between sites, based on our knowledge of what is
-%% already staged on each site
-
-%% TODO: Is anything else interesting happening here in our group?
-
-%% \subsection{Language development}
-
-%% TODO: describe how it becomes more functional as time passes, as is
-%% becoming more popular. can ref mapreduce here\cite{MAPREDUCE} eg map
-%% operator extension - looks like foreach; and maybe some other
-%% popular-ish functional language eg F\#
-
-%% TODO type-inference - implemented by Milena but not put into
-%% production.
-
-%% TODO libraries/code reuse - some traditional language stuff there but
-%% orthogonal to that is how to express transformation catalog (which ties
-%% together language declarations with site declarations, and hence makes
-%% procedures vs sites not completely orthogonal)
-
-%% TODO unification of procedures and functions (a historical artifact),
-%% and possibly of mappers
-
-%% \subsection{Debugging}
-
-%% TODO: debugging of distributed system - can have a non-futures section
-%% on what is available now - logprocessing module, as well as
-%% mentioning CEDPS\cite{CEDPS} as somewhat promising(?) for the future.
-
-%% \subsection{Swift as a library}
-%% Could existing programs execute Swift calls through a library
-%% approach? The answer to this is certainly ``yes''. (?)
-
-%% \subsection{Swift library / source code management}
-
-%% (TODO benc: unclear what is meant by this paragraph. it was originally in the
-%% introduction, but as it appears to talk about something which does not (yet?)
-%% exist, then it is probably better being absorbed into the future section)
-
-%% Swift does not yet have a notion of libraries. Swift programs execute as
-%% if all procedures called in the script are present in a single logical
-%% source file and are thus passed to the Swift virtual machine all at once.
-
\section{Comparison to Other Systems}
\label{Related}
@@ -1255,13 +1136,13 @@
Strand~\cite{STRAND_1989} and PCN~\cite{PCN_1993} allow composition of
distributed or parallel components, but usually require the components
to be programmed in specific languages and linked with the systems;
-where we need to coordinate procedures that may already exist (e.g.,
-legacy applications), were coded in various programming languages and
-run in different platforms and architectures. Linda defines a set of
-coordination primitives for concurrent agents to put and retrieve
-tuples from a shared data space called a tuple space, which serves as
-the medium for communication and coordination. Strand and PCN use
-single-assignment variables as coordination
+contrarily, we need to coordinate procedures that may already exist
+(e.g., legacy applications), were coded in various programming
+languages and run in different platforms and architectures. Linda
+defines a set of coordination primitives for concurrent agents to put
+and retrieve tuples from a shared data space called a tuple space,
+which serves as the medium for communication and coordination. Strand
+and PCN use single-assignment variables as coordination
mechanism. Like Linda, Strand and PCN are data driven in the sense
that the action of sending and receiving data are decoupled, and
processes execute only when data are available.
@@ -1276,7 +1157,7 @@
and schedules the execution of programs in a large cluster of
commodity machines. The system is made fault tolerant by checking
worker nodes periodically and reassigning failed jobs to other worker
-nodes. Sawzall\cite{Sawzall_2005} is an interpreted language that
+nodes. Sawzall~\cite{Sawzall_2005} is an interpreted language that
builds on MapReduce and separates the filtering and aggregation phases
for more concise program specification and better parallelization.
@@ -1290,7 +1171,7 @@
\item Programming model: MapReduce only supports key-value pairs as
input or output datasets and two types of computation functions -
- map and reduce; where Swift provides a type system and allows the
+ map and reduce; Swift provides a type system and allows the
definition of complex data structures and arbitrary computation
procedures.
@@ -1306,7 +1187,7 @@
with computations.
\item Execution environment: MapReduce schedules computations within a
- cluster with shared Goojgle File System, where Swift schedules across
+ cluster with shared Google File System, where Swift schedules across
distributed Grid sites that may span multiple administrative
domains, and deals with security and resource usage policy issues.
@@ -1317,7 +1198,7 @@
Service. BPEL is starting to be tested in scientific contexts. While
BPEL can transfer data as XML messages, for very large scale datasets,
data exchange must be handled via separate mechanisms. In BPEL 1.0
-specification, it does not have support for dataset iterations. An
+specification there is no support for dataset iterations. An
application with repetitive patterns on a collection of datasets could
result in large, repetitive BPEL documents~\cite{Sedna_2007}, and BPEL
is cumbersome if not impossible to write for computational
@@ -1349,6 +1230,115 @@
abstraction, and workflow restart, reliable execution over multiple
Grid sites, and (via Falkon and CoG coasters) fast job execution.
+\section{Future work}
+\label{Future}
+
+Swift is an actively developed project. Current directions in Swift
+development focus on improvements for short-running tasks, massively
+parallel resources, data access mechanisms, site management, and
+provenance.
+
+\subsection{Provisioning for tasks of finer granularity}
+
+In some applications the execution time for a program is very
+short. In such circumstances, execution time can become dominated by
+GRAM and LRM overhead. A resource provisioning system such as
+Falkon~\cite{Falkon_2008} or the CoG coaster mechanism developed for
+Swift can be used to ameliorate this overhead, by incurring the
+allocation overhead once per worker node. Both of these mechanisms can
+be plugged into Swift straightforwardly through the CoG provider API.
+
+\subsection{Scripting on thousands of cores}
+
+Systems such as the Sun Constellation~\cite{SunConstellation_2008} or
+IBM BlueGene/P~\cite{BGP_2008} have hundreds of thousands of cores,
+and systems with millions of cores are planned. Scheduling and
+managing tasks running at this scale is a challenging problem in
+itself and relies of the rapid submission of tasks as noted
+above. Swift applications currently do run on these systems by
+scheduling Coasters workers using the standard job submission
+techniques and employing an internal IP network.
+
+\subsection{Filesystem access optimizations}
+
+Similarly, some applications deal with files that are uncomfortably
+small for GridFTP (on the order of tens of bytes). For this, a
+lightweight file access mechanism provided by CoG Coasters can be
+substituted for GridFTP. When running on HPC resources, the thousands
+of small accesses to the filesystem may create a bottleneck. To
+approach this problem, we have investigated application needs and
+initiated a set of Collective Data Management (CDM)~\cite{CDM_2009}
+primitives to mitigate these problems.
+
+\subsection{Provenance}
+\label{Provenance}
+
+Swift produces log information regarding the provenance of its output files.
+In an existing development module, this information can be imported
+into relational and XML databases for later querying. Providing an
+efficient query mechanism for such provenance data is an area of
+ongoing research; whilst many queries can be easily answered
+efficiently by a suitably indexed relational or XML database, the lack
+of support for efficient transitive queries can make some common
+queries involving either transitivity over time (such as 'find all
+data derived from input file X') or over dataset containment (such as
+'find all procedures which took an input containing the file F')
+expensive to evaluate and awkward to express.
+
+%% \subsection{GUI workflow design tools}
+
+%% In contrast to a text-oriented programming language like SwiftScript,
+%% some scientists prefer to design simple programs using GUI design tools.
+%% An example of this is the LONI Pipeline tool\cite{LONIPIPELINE}. Preliminary
+%% investigations suggest that scientific workflows designed with that tool
+%% can be straightforwardly compiled into SwiftScript and thus benefit from
+%% Swift's execution system.
+
+%% \subsection{Site selection research}
+
+%% TODO: data affinity between sites, based on our knowledge of what is
+%% already staged on each site
+
+%% TODO: Is anything else interesting happening here in our group?
+
+%% \subsection{Language development}
+
+%% TODO: describe how it becomes more functional as time passes, as is
+%% becoming more popular. can ref mapreduce here\cite{MAPREDUCE} eg map
+%% operator extension - looks like foreach; and maybe some other
+%% popular-ish functional language eg F\#
+
+%% TODO type-inference - implemented by Milena but not put into
+%% production.
+
+%% TODO libraries/code reuse - some traditional language stuff there but
+%% orthogonal to that is how to express transformation catalog (which ties
+%% together language declarations with site declarations, and hence makes
+%% procedures vs sites not completely orthogonal)
+
+%% TODO unification of procedures and functions (a historical artifact),
+%% and possibly of mappers
+
+%% \subsection{Debugging}
+
+%% TODO: debugging of distributed system - can have a non-futures section
+%% on what is available now - logprocessing module, as well as
+%% mentioning CEDPS\cite{CEDPS} as somewhat promising(?) for the future.
+
+%% \subsection{Swift as a library}
+%% Could existing programs execute Swift calls through a library
+%% approach? The answer to this is certainly ``yes''. (?)
+
+%% \subsection{Swift library / source code management}
+
+%% (TODO benc: unclear what is meant by this paragraph. it was originally in the
+%% introduction, but as it appears to talk about something which does not (yet?)
+%% exist, then it is probably better being absorbed into the future section)
+
+%% Swift does not yet have a notion of libraries. Swift programs execute as
+%% if all procedures called in the script are present in a single logical
+%% source file and are thus passed to the Swift virtual machine all at once.
+
\section{Conclusion}
\label{Conclusion}
@@ -1358,8 +1348,8 @@
contain rich operators, primitives, and libraries for large classes of
useful operations such as string, math, internet, and file
operations. In contrast, Swift scripts typically contain very little
-code that manipulates data directly. They contain instead the "data
-flow recipes" and input/output specifications of each program
+code that manipulates data directly. They contain instead the ``data
+flow recipes'' and input/output specifications of each program
invocation such that the location and environment transparency goals
can be implemented automatically by the Swift environment. This simple
model has demonstrated many successes as a tool for scientific
@@ -1424,4 +1414,3 @@
% \verb|$Id$|
\end{document}
-
More information about the Swift-commit
mailing list