[Swift-commit] r3362 - text/parco10submission

noreply at svn.ci.uchicago.edu noreply at svn.ci.uchicago.edu
Tue Jun 15 15:17:01 CDT 2010


Author: wozniak
Date: 2010-06-15 15:17:01 -0500 (Tue, 15 Jun 2010)
New Revision: 3362

Modified:
   text/parco10submission/paper.tex
Log:
Reorg Intro


Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2010-06-15 20:00:20 UTC (rev 3361)
+++ text/parco10submission/paper.tex	2010-06-15 20:17:01 UTC (rev 3362)
@@ -113,6 +113,55 @@
 %TODO: Provide a compelling example here, perhaps with
 % a code segment, of the power of Swift, in a single paragraph.
 
+\subsection{Rationale}
+
+The emergence of large-scale production computing infrastructure such
+as clusters, grids and high-performance computing (HPC), and the
+inherent complexity of programming on these systems, necessitated a
+new approach. Swift was developed to create a higher-level language
+that focuses not on the details of executing sequences or
+``pipelines'' of programs, but rather on specific issues that arise
+from the concurrent execution of disparate computational tasks at
+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.
+
+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.
+
+The remainder of this paper is organized as follows. In
+Section~\ref{Language} we present the major concepts and language
+structure of Swift. Section~\ref{Execution} provides details of the
+implementation, including the distributed architecture that enables
+Swift applications to run on distributed resources.
+Section~\ref{Applications} demonstrates real-world applications using
+Swift on scientific projects. Section~\ref{Related} describes Swift in
+the context of other related systems. Section~\ref{Future} highlights
+ongoing and future work in the Swift project, and we offer concluding
+remarks in Section~\ref{Conclusion}.
+
+\section{The SwiftScript language}
+\label{Language}
+
 \subsection{Swift language concepts}
 
 The Swift programming model is data-oriented: it encapsulates the
@@ -185,53 +234,7 @@
 data files are associated with the logical representation of Swift's
 data model of variables and collections.
 
-\subsection{Rationale for creating Swift}
 
-Why do we need Swift? Why create yet another scripting language for
-the execution of application programs when so many exist?  Swift was
-developed to create a higher-level language that focuses not on the
-details of executing sequences or ``pipelines'' of programs, but
-rather on specific issues that arise from scale.
-
-% These issues,
-% however, once identified, seem to equally well apply to, and benefit
-% the execution of, application pipelines that are not large-scale and
-% not necessarily distributed. Our motivation for developing Swift is
-% based on the following premises:
-
-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.
-
-What's missing 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.
-
-% TODO: Refine and condense this rationale.
-
-In the remainder of this paper, we present the language,
-details of the implementation, application use-cases and ongoing
-research. TODO: refine this sentence.
-
-\section{The SwiftScript language}
-\label{Language}
-
 \subsection{Language basics}
 
 A Swift script describes data, application components, invocations
@@ -1317,6 +1320,7 @@
 active development group; releases roughly every 2 months.
 
 \section{Comparison to Other Systems}
+\label{Related}
 
 %% As a ``parallel scripting language'', Swift is typically used to
 %% specify and execute scientific ``workflows'' - which we define here as
@@ -1447,11 +1451,8 @@
 
 TODO: Polish conclusion - was pasted here from intro and doesnt fit yet.
 
-\section{Acknowledgements}
+\section{Acknowledgments}
 
-TODO: authors beyond number 3 go here according to ACM style guide, rather
-than in header
-
 TODO: NSF/DOE grant acknowledgements
 
 \section{TODO}




More information about the Swift-commit mailing list