[Swift-commit] r3887 - text/parco10submission
noreply at svn.ci.uchicago.edu
noreply at svn.ci.uchicago.edu
Fri Jan 7 10:17:35 CST 2011
Author: dsk
Date: 2011-01-07 10:17:34 -0600 (Fri, 07 Jan 2011)
New Revision: 3887
Modified:
text/parco10submission/ResponseToReviews.txt
text/parco10submission/paper.tex
Log:
changes, some responses to reviewers being handled
Modified: text/parco10submission/ResponseToReviews.txt
===================================================================
--- text/parco10submission/ResponseToReviews.txt 2011-01-07 06:11:55 UTC (rev 3886)
+++ text/parco10submission/ResponseToReviews.txt 2011-01-07 16:17:34 UTC (rev 3887)
@@ -49,17 +49,23 @@
On the other hand, I don't see much scientific merit in the paper. The paper reads more like a Swift user manual than a scientific paper. For the language design, the only thing that might be novel is the notion of mapped type, but I consider it to be quite minor. I also don't see any new ideas in the data-flow dependency based execution model.
->>> Novelty and scientific merit:
+>>> Response:
+We believe that our discussion of related work shows that there is no other language that does what Swift does. We also believe that the decisions we have made in creating Swift, as a simple minimal language with a function model for evaluating a large set of individual applications on both parallel and distributed systems of extreme scale using the concept of single-assignment futures to highly effectively exploit implicit parallelism provides the scientific merit of the paper.
+
<<<
For the distributed execution, one important missing piece is performance evaluation. Data locality is very important for data-intensive applications. As I understand it, data have to be moved in and out the clusters. So, understanding the cost of scheduling and data transfer is very important to validate the Swift design. Perhaps, it was
-published somewhere else, but it would be nice to discuss it in this paper. Here are some more detailed comments:
+published somewhere else, but it would be nice to discuss it in this paper.
->>> Performance evaluation:
+>>> Response:
+We have added a new section, "5. Performance Characteristics" in response to this point.
+
<<<
+Here are some more detailed comments:
+
1. Swift uses restart log to reuse the results of successfully completed components. The paper mentioned "appropriate manual intervention". This seems to be something you can almost completely automate. Based on my experiences with large-scale and long running applications, this can be very useful.
>>> Automation of restart
@@ -86,8 +92,12 @@
For those who might not be familiar with the Karajan language, it would be useful to add a reference to the related work.
->>> Reference to Karajan: <<<
+>>> Response:
+We have added such a reference
+
+<<<
+
It would be helpful to include some discussion on the "auto-parallelization" capability (achieved via data flow analysis?).
>>> auto-parallelization
@@ -114,9 +124,10 @@
Should "frames" be "f" in this case?
->>> typo
+>>> Response:
The typo has been corrected.
+
<<<
Reviewer #3: This is an interesting paper aimed at the practical problem of
@@ -125,9 +136,10 @@
fine. There are a number of small errors which should have been
caught by proofreading the manuscript.
->>> typos
+>>> Response:
typos and grammar have been corrected by a fresh complete proofreading.
+
<<<
The most substantive comment I have concerns examples 4.3 and 4.4. I
@@ -148,18 +160,18 @@
language, so perhaps "SwiftScript" should be replaced by "Swift"
everywhere.
->>>
+>>> Response:
-this has been done.
+This has been done. SwiftScript no longer appears.
<<<
2. It's a bit awkward that "single assignment" is used in section 2.1
but not defined until section 2.3.
->>>
+>>> Response:
-fixed.
+This has been fixed.
<<<
@@ -167,18 +179,18 @@
procedure should have an angle input in addition to the image input
(this is corrected on p.6).
->>>
+>>> Response:
-fixed.
+This has been fixed.
<<<
4. In section 2.2, should rotate be invoked as "rotate(f, 180)" instead
of "rotate(frames, 180)"?
->>>
+>>> Response:
-fixed.
+This has been fixed.
<<<
@@ -189,23 +201,23 @@
probably should be defined. Other acronyms: GRAM, fMRI (and FMRI,
cf. Fig. 2, which should probably be fMRI).
->>>
+>>> Response:
-RDBMS removed.
-FMRI fixed.
+RDBMS has been removed.
+FMRI has been removed.
GRAM doesn't seem to need explanation, it's cited where first used.
-still need to think about acronyms in Figure 1.
+The acronyms in Figure 1 are defined in the caption.
<<<
6. All these appear: "stage in", "stage-in", "stagein". Please be
consistent (similarly for stage out).
->>>
+>>> Response:
-fixed.
+This has been fixed.
- <<<
+<<<
7. The mysterious numbers '12, 1000, 1000, "81 3 3"' in example 4.1
might merit an explanation.
@@ -252,15 +264,19 @@
12. "Karajan" is mentioned several times, there really should be short
definition of it and a reference to it in the bibliography.
->>> <<<
+>>> Response:
+This has been fixed.
+
+<<<
+
13. Many of the references look incomplete; journal references really
should have page numbers, some references are missing a year.
Reference 8 severely mangles "Bresnahan".
->>>
+>>> Response:
-all Refs fixed.
+This has been fixed.
<<<
@@ -276,8 +292,13 @@
would one want to _compile_ a scripting language? It seems more natural
(to this naive reader) to have an interpreter or a translator.
->>> <<<
+>>> Response:
+This has been fixed. We now more accurately say:
+Swift is implemented by generating and executing a Karajan program.
+
+<<<
+
16. The coaster idea looks quite interesting, could this be expanded,
or could an example with coasters be constructed?
@@ -286,16 +307,20 @@
17. Table 1, 1st row, 3rd column: should it be f->data.txt instead of
f->file.txt?
->>> <<<
+>>> Response:
+This has been fixed.
+
+<<<
+
18. There are many (too many to list) typos, missing words, mistakes
such as "en queued" instead of "enqueued", subject/verb mismatches of
number and/or tense. A careful proofreading is sorely needed.
->>>
+>>> Response:
-fixed.
+This has been fixed.
<<<
Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex 2011-01-07 06:11:55 UTC (rev 3886)
+++ text/parco10submission/paper.tex 2011-01-07 16:17:34 UTC (rev 3887)
@@ -798,7 +798,8 @@
\begin{table}[t]
\begin{center}
- \begin{tabular}{|l|p{3.5cm}|p{5cm}|}
+ \begin{footnotesize}
+ \begin{tabular}{|l|p{4cm}|p{5cm}|}
\hline
{\bf Mapper name } &
{\bf Description} &
@@ -808,9 +809,9 @@
\begin{minipage}{5cm}
\vspace{2mm}
\begin{center}
- {\tt file f<"data.txt">;} \\
+ {\tt file f <"data.txt">;} \\
--- \\
- $f \rightarrow {\tt file.txt}$
+ $f \rightarrow {\tt data.txt}$
\vspace{2mm}
\end{center}
\end{minipage}
@@ -821,10 +822,11 @@
\begin{minipage}{5cm}
\vspace{2mm}
\begin{center}
- {\tt file f<filesys\_mapper;} \\
- {\tt \ \ \ \ \ \ \ "file*.txt">;} \\
+ {\tt file f <filesys\_mapper;} \\
+ {\tt \ \ \ \ \ \ \ prefix="data",} \\
+ {\tt \ \ \ \ \ \ \ suffix=".txt">;} \\
--- \\
- $f_0 \rightarrow {\tt file2.txt}$
+ $f_0 \rightarrow {\tt data2.txt}$
\end{center}
\end{minipage}
\\
@@ -834,15 +836,17 @@
\begin{minipage}{5cm}
\vspace{2mm}
\begin{center}
- {\tt file f<simple\_mapper;} \\
- {\tt \ \ \ \ \ \ \ "file.*.txt">;} \\
+ {\tt file f <simple\_mapper;} \\
+ {\tt \ \ \ \ \ \ \ prefix="data.",} \\
+ {\tt \ \ \ \ \ \ \ suffix=".txt">;} \\
--- \\
- $f.\textrm{red} \rightarrow {\tt file.red.txt}$
+ $f.\textrm{red} \rightarrow {\tt data.red.txt}$
\end{center}
\end{minipage}
\\
\hline
\end{tabular}
+ \end{footnotesize}
\end{center}
\caption{Swift built-in mappers: conceptual syntax}
\label{mappertable}
@@ -974,7 +978,7 @@
\begin{figure*}[htbp]
\begin{center}
\includegraphics{img/swift-model}
- \caption{Swift site model}
+ \caption{Swift site model. (CoG = Commodity Grid~\cite{Karajan}, OSG = Open Science Grid, AWS = Amazon Web Services, HPC = High Performance Computing, BG/P = BlueGene/P.)}
\label{FigureSwiftModel}
\end{center}
\end{figure*}
More information about the Swift-commit
mailing list