[Swift-commit] r3378 - text/parco10submission

[noreply at svn.ci.uchicago.edu]

Author: wozniak
Date: 2010-06-16 00:31:18 -0500 (Wed, 16 Jun 2010)
New Revision: 3378

Modified:
   text/parco10submission/paper.tex
Log:
aspell


Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2010-06-16 05:23:16 UTC (rev 3377)
+++ text/parco10submission/paper.tex	2010-06-16 05:31:18 UTC (rev 3378)
@@ -91,10 +91,10 @@
 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
+minimal set of language constructs to specify 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
+tasks that existing scripting languages do well. Swift regularizes and
 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
@@ -144,7 +144,7 @@
 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
+achieving location transparency and automated parallel execution is
 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
@@ -366,7 +366,7 @@
      step[ix] = simulate(step[ix-1]);
    }
 \end{verbatim}
-This fragment will initialise the 0-th element of the \verb|step| array
+This fragment will initialize 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.
 
@@ -388,7 +388,7 @@
    y=p(x);
    z=q(x);
 \end{verbatim}
-whilst in this fragment, execution is serialised by the variable
+whilst in this fragment, execution is serialized by the variable
 \verb|y|, with procedure \verb|p| executing before \verb|q|:
 \begin{verbatim}
    y=p(x);
@@ -731,11 +731,11 @@
 script.  This separates application code from system configuration.
 The site catalog may contain definitions for multiple sites in which
 case execution will be attempted on all sites. In the presence of
-multiple sites, it is necessary to choose between the avalable sites.
+multiple sites, it is necessary to choose between the available sites.
 The Swift \emph{site selector} achieves this by maintaining a score for
 each site which determines the load that Swift will place on that site.
-As a site is successful in executing jobs, this score wil be increased
-and as the site is uncsuccessful, this score will be cdecreased. In
+As a site is successful in executing jobs, this score will be increased
+and as the site is uncsuccessful, this score will be decreased. In
 addition to selecting between sites, this mechanism provides some
 dynamic rate limiting if sites fail due to overload~\cite{FTSH_2003}.
 
@@ -753,7 +753,7 @@
 The functional  nature of SwiftScript provides a clearly defined
 interface to imperative components, in addition to allowing Swift great
 flexibility in where and when it runs component programs, allows those
-imperative components to be treated as atmoic components which can be
+imperative components to be treated as atomic components which can be
 executed multiple times for any given SwiftScript procedure invocation.
 This facilitates three different reliability mechanisms implemented by
 the runtime that need not be exposed at the language level: \emph{retries},
@@ -774,13 +774,13 @@
 will fail resulting ultimately in the entire script failing.
 
 In such a case, Swift provides a \emph{restart log} which encapsulates
-which procedure invocations have been succesfully completed. After
+which procedure invocations have been successfully completed. After
 appropriate manual intervention, a subsequent Swift run may be started
 with this restart log; this will suppress re-execution of already
 executed invocations but otherwise allow the script to continue.
 
 A different class of failure is when jobs are submitted to a site but
-are then enqueued for a very long time on that site. This is a failure
+are then en queued for a very long time on that site. This is a failure
 in site selection, rather than in execution. Sometimes it can be a
 soft failure, in that the job will eventually run on the chosen site -
 the site selector has improperly chosen a very heavily loaded site;
@@ -789,11 +789,11 @@
 selector has improperly chosen a site which is not executing jobs.
 
 To address this situation, Swift provides for \emph{job replication}.
-After a job has been enqueued on a site for too long, a second
+After a job has been en queued on a site for too long, a second
 instance of the job will be submitted (again undergoing site
 selection, stagein, execution and stageout); this will continue up to
 a defined limit. When any of those jobs begins executing, all other
-replicas will be cancelled.
+replicas will be canceled.
 
 \subsection{Avoiding job submission penalties}
 
@@ -823,7 +823,7 @@
 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
-used, with excessive serialisation; or (in the other direction) result
+used, with excessive serialization; or (in the other direction) result
 in an excessive number of GRAM job submissions. Coaster workers can be
 queued and executed before all of the work that they will eventually
 execute is known, so can get more work done per GRAM job submission,
@@ -832,8 +832,8 @@
 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 beginning of dependent jobs) is delayed (in the worst case,
+activity dependent on the first job in a cluster must wait for all of
 the jobs to run).
 
 \subsection{Features to support use on dynamic resources}
@@ -853,7 +853,7 @@
 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
+different behavior, both with respect to other sites at the same
 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