[Swift-commit] r3934 - text/parco10submission

noreply at svn.ci.uchicago.edu noreply at svn.ci.uchicago.edu
Mon Jan 10 12:24:39 CST 2011


Author: wilde
Date: 2011-01-10 12:24:39 -0600 (Mon, 10 Jan 2011)
New Revision: 3934

Modified:
   text/parco10submission/ResponseToReviews.txt
Log:
Made final comments in the ResponseToReviews file.

Modified: text/parco10submission/ResponseToReviews.txt
===================================================================
--- text/parco10submission/ResponseToReviews.txt	2011-01-10 18:07:47 UTC (rev 3933)
+++ text/parco10submission/ResponseToReviews.txt	2011-01-10 18:24:39 UTC (rev 3934)
@@ -60,25 +60,51 @@
 
 >>> Response:
 
-We have added a new section, "5. Performance Characteristics" in response to this point.
+We have added a new section, "5. Performance Characteristics" in
+response to this point. Additional tests are being developed and run,
+so these results may be further refined before publication. Some
+results from prior publications have been cited and included here,
+which show the overlap of data transfer and processing to address the
+issue above.
 
 <<<
 
 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.
+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
 
+The "manual intervention" referred to the correction of whatever
+caused the script to fail. For example, a missing data file. Since the
+Swift restart mechanism *is* fully automated, this phrase was removed.
+
 <<<
 
-2.        Swift reduces job submission cost using clustering.  It is not clear to me if a subgraph can be batched together by your clustering technique.  This obviously requires a little bit of analysis of the data-flow graph to do it properly.  But it could be quite useful to achieve better data locality.
+2.  Swift reduces job submission cost using clustering.  It is not
+clear to me if a subgraph can be batched together by your clustering
+technique.  This obviously requires a little bit of analysis of the
+data-flow graph to do it properly.  But it could be quite useful to
+achieve better data locality.
 
 >>> Clustering
 
+This section has been clarified. Swift will group tasks together based
+on their expected time duration and their readiness to run. So a
+cluster batch could include tasks from multiple sub-graphs. But its
+based on 
+
 <<<
 
-3.        In terms of programming models, modern systems such as Microsoft's DryadLINQ and Google's FlumeJava successfully integrate data-flow constructs into state of the art programming languages (C# and Java).  This integration approach is quite nice and powerful. It would be nice if the authors can compare Swift with these two systems.
+3.  In terms of programming models, modern systems such as Microsoft's
+DryadLINQ and Google's FlumeJava successfully integrate data-flow
+constructs into state of the art programming languages (C# and Java).
+This integration approach is quite nice and powerful. It would be nice
+if the authors can compare Swift with these two systems.
 
 >>> Response:
 
@@ -104,12 +130,18 @@
 
 >>> auto-parallelization
 
+This is now discussed in much more detail, in section 2.
+
 <<<
 
 Out of the four application examples presented, two of the cases (4.3 and 4.4) do not contain enough details to support the discussion; deleting the two examples should not affect the clarity of the paper.
 
 >>> Examples: clarify or delete 
 
+We have completely revised the application example section (4).  It
+now shows only two app examples, but does so in much more precise
+detail, to provide a better understanding of what using Swift entails.
+
 <<<
 
 It would be helpful to elaborate more in example 4.2 on how each task/job gets scheduled onto Ranger nodes or how Swift interacts with the local batch job scheduler, which would in turn help audience understand better how SwiftScript could be used for a certain class of applications on a more tightly coupled massive computing environment (such as
@@ -117,6 +149,9 @@
 
 >>> 4.2 - task scheduling on Ranger 
 
+As Sec 4 is revised considerably, this information has been included
+in Secs. 2 & 3.
+
 <<<
 
 There are a few minor typos in the manuscript.
@@ -152,6 +187,8 @@
 
 >>> examples 4.3 and 4.4: annotate or delete
 
+Addressed and revised completely, as mentioned above.
+
 <<<
 
 Further comments:
@@ -252,14 +289,18 @@
 
 10. Section 4.2, what is an "emblem experiment"?
 
->>> <<<
+>>>
 
+This has been removed in the revision of Sec 4.
+
+<<<
+
 11. The margins in sections 4.2 and 4.4 need fixing as some lines
 run completely off the page.
 
 >>> 
 
-fixed in 4.2 - not sure about the state of 4.4 yet
+This has been addressed in the revision of Sec 4.
 
 <<<
 
@@ -331,44 +372,3 @@
 This has been fixed.
 
 <<<
-
-====  Other improvement notes
-
-mention futures in parco paper, show them visually to show fine grain
-
-mention habanero  (c and java) and other fresh stack languages (x10)
-compare to GEL - from SIngapore
-
-mention csp bsp sim and diff to mpi (IPO)
-
-Why a new model?
-
-examine determinism
-
-examine language vs library
-
-examine how it builds on karajan
-
-
----
-
-Innov: fine grained parallelism; no need for flow analysis;
-sep of concerns: how throttling and site mgmt are isolated
-
-How we can manage data locality
-
-How restart is more transparent than it sounds here
-
-Fine: how work takes off before a proc returns
-
-Add table of critical benchmarks on multi sys types
-
-How complex flows are easily composed
-
-How types and mappers encapsulate complexity
-
-2.3 order of exec: show more complex patterns here or later
-
-Second 2 is the part that reads like a LRM; make it more interesting
-
-2.5 don't say marker types




More information about the Swift-commit mailing list