From gcf@boss.npac.syr.edu Tue Feb 2 08:17 EST 1999 Received: from boss.npac.syr.edu (boss.npac.syr.edu [128.230.117.20]) by postoffice.npac.syr.edu (8.9.1a/8.9.1) with SMTP id IAA21227; Tue, 2 Feb 1999 08:17:10 -0500 (EST) Received: from localhost (gcf@localhost) by boss.npac.syr.edu (950413.SGI.8.6.12/8.6.6) with SMTP id IAA23443; Tue, 2 Feb 1999 08:17:09 -0500 Message-Id: <199902021317.IAA23443@boss.npac.syr.edu> X-Authentication-Warning: boss.npac.syr.edu: Host localhost didn't use HELO protocol Reply-to: gcf@npac.syr.edu To: ncaza@boss.npac.syr.edu, kea@npac.syr.edu Subject: Please Process Date: Tue, 02 Feb 1999 08:17:09 -0500 From: Geoffrey Fox Content-Type: text Content-Length: 20042 Status: RO Nicole should learn from Terri? Geoffrey Fox gcf@npac.syr.edu, http://www.npac.syr.edu Director of NPAC and Professor of Physics and Computer Science Phone 3154432163 (Npac central 3154431723) Fax 3154434741 ------- Forwarded Message Date: Mon, 01 Feb 1999 14:49:54 +1030 From: Michael Oudshoorn To: gcf@nova.npac.syr.edu cc: Michael Oudshoorn Subject: Referee's Report for Concurrency: Practice and Experience - --------------F80E6030E7720525319DC2C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Geoffrey, Please find by referee's report below. Let me know if there are any problems and I will send a paper version if necessary. Cheers Michael Oudshoorn - -- Dr. Michael Oudshoorn Department of Computer Science The University of Adelaide Adelaide SA 5005 Australia Phone: +61 8 8303 4478 Fax: +61 8 8303 4366 E-mail: michael@cs.adelaide.edu.au URL: http://www.cs.adelaide.edu.au/~michael - ----- cut here ----- C: Paper Nuumber: G392 Date: 1 February, 1999 Paper Titls: Synchronization Transformations for Parallel Computing Author(s): Pedro C. Dinz and Martin C. Rinhard Referee: Michael Oudshoorn Address: Department of Computer Science University of Adelaide Adelaide SA 5005 Australia Signature: Michael Oudshoorn Referee Recommendations: REJECT D: Referee Comments (For Editor Only) The paper is littered with spelling errors and this contributes to the delay in reviewing the paper. I found that the paper is really more of a conference paper than an archival journal paper. The application area that the authors discuss is appropriate for the journal, but too much is left unsaid, or said poorly, to make it publishable in its current form. For example, the paper discusses several algorithms without giving a broad overview in the main body of the text. Details are found in the appendix at the end of the paper and the reader is forced to wade through the code to understand what the algorithm actually does. I think that the content is publishable but only after the paper has undergone a substantial revision - more than I am able to elaborate in this review. For this reason I have recommended that the paper be rejected at this stage and the authors ought to be encounraged to revise the paper and resubmit it for refereeing again. E. Referee Comments (For Author and Editor) Paper Number: G392 Date: 1 February, 1999 The paper addresses the issue of eliminating excessive amounts of lock acquisition and release within a parallelizing compiler. The motivation of the work appears to be that the authors wanted to improve the performance of their compiler, yet the paper claims that the algorithms developed are more generally useful and can reduce the volume of lock aquisition and release in more general cases. This claim is never substantiated. The algorithms presented in the appendices and generally discussed in the paper work with multiple locks, but it is not clear that the compiler in question generates multiple locks. This deficiency makes it difficult to know precisely what is happening in the experiments conducted by the authors. It would be helpful to the reader to show some original source code, the corresponding ICFG before lock elimination etc and after lock elimination is completed. This confusion stems in part from the text at the top of page 32 of the manuscript where it the reader is lead to believe, or may interpret the text as such, that the compiler only uses a single lock. If this is indeed the case, then the compiler and the test cases discussed do not fully exercise the algorithms presented by the authors. As a result, the reader may not be convinced that the algorithms have been fully tested and demonstrated to function in the presence of multiple locks. This is important given that the paper goes to great pains to claim that it will work with multiple locks when the algorithms are discussed. Page 13 of the manuscript gives some figures indicating how the abstractions appliced reduce the size of the ICFG. It is unclear what the authors mean when they say "to reduce the size of the ICFG from as low as 25% to a maximum of 92% with an average of 57%". In comparison to what - the original ICFG? i also do not understand how to interpret the claim "from as low as 25%". The discussion on lock movement is awkward for the reader as it becomes clear at an early stage that moving locks as discussed leads to excessive serialisation of the code if the author is not carefull. It is not until the reader fights their way through to the discussion on false exclusion policies (page 21) that the matter is resolved (partially). It is only partially resolved since the reader is never told the size of the critical sections in the bounded policy wven though this policy is used in the experiments. Page 23 explains the reachability tree for release and acuire nodes. This discussiion is unclear because the reader is referred to the corresponding figures and left to deduce what is happening. The obvious question is why does a call and return node seem to inhibit the growth of the reachability tree in the case of release and acquire nodes respectively? This question is not addressed by the paper. Finally, the experiments conducted are interesting, but a very small sample space. It is not clear if the results obtained are representative. Some simulation studies where artificial ICFG's are produced and lock movement and elimination performed prior to "execution" would allow some trends to be discovered. For example, the reader is left with the feeling that it is the frequency with which locks are aquired and released that is the key issue, and it is really the amount of looping within a program that determines any improvement gain that might be observed. What is the critical value here? How often does the program need to loop before any benefits are seen? Is there a relationship to the amount of computation that takes place inside the critical sections that is important? How does communication between parallel computational elements affect things? I would prefer to see the paper address such questions. This would make the paper broader and, therefore, appeal to a larger readership. F. Presentation Changes Title Changes: None Abstract Changes: Providing as much detail as you have in the abstract regarding the experimental results of the algorithm was of little interest to me as I started to read the paper. I would rather see the abstract tell me what the paper is about and what the general outcome is rather than having a third of it devoted to telling me about the experimental results at a time when I do not even know what the experiments are or what is being compared in order to claim a performance improvement. Reference Changes/Additions: None required. Other Comments (Grammar etc): The paper is littered with spelling errors, typographical errors, sentences which commence with conjunctions and the like. I seriously doubt that the paper was proofread before submission. As an exmaple, consider page 28 of the manuscript. Line 7 reads "exists synchronisation free path" and it should be "exists a synchronisation free path". Line 10 reads: "the flow of control for the case of a release", and it should be "the flow of control in the case of a release node". Line 10-11 reads "Because rechability [sic] trees"; the sentence should not start with the word "Because" and there is no excuse for mis-spelling reachability (and it is not the only place it is mis-spelt). The word "because" is used several times to start sentences. Line 15 reads: "the discussion and avoid pathological algorithmic cases we normalize", it should read "the discussion we avoid pathological algorithmic cases, we normalize". However, this is hardly an improvment since the use of personal pronouns such as "we" are best avoided in good scientific writting. Line 18 reads: "These simplification account" and it should be "These simplifications account". If we consider page 29 of the manuscript, we find the following problems. Line 2-3 reads "node it defines a clearly empty critical section". This is probably better worded as "node it clearly defines an empty critical section". Line 6 reads: "for a possible lock elimination" which is better written as "for possible lock elimination". The same problem occurs on line 7. Line 9 reads: "In this normalized form of the ICFG the upper bound" and it should be: "In this normalized form of the ICFG, the upper bound". Line 10 gives a measure of the copmlexity of the elimination algorithm without explanation. if you are not going to explain it to the reader, why bother stating it? You don't even give the reaer the chance to verify that it is correct. The final 3-4 lines of the page are not clear. They need to be rewritten so that you message is clearly conveyed to the reader and they are not required to second guess what you might mean. Once again, explain the complexity figures claimed. Page 24 has the following spelling errors, in addition to problems similar to that described above: "skratch", "rechability" and "reacheability". - --------------F80E6030E7720525319DC2C0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Geoffrey,

Please find by referee's report below.  Let me know if there are any problems and I will send a paper version if necessary.

Cheers

Michael Oudshoorn

--
Dr. Michael Oudshoorn
Department of Computer Science
The University of Adelaide
Adelaide   SA   5005
Australia

Phone: +61 8 8303 4478
Fax: +61 8 8303 4366
E-mail: michael@cs.adelaide.edu.au
URL: http://www.cs.ade laide.edu.au/~michael
 
 

----- cut here -----

C: Paper Nuumber:    G392
Date:                 1 February, 1999

Paper Titls:    Synchronization Transformations for Parallel Computing
Author(s):      Pedro C. Dinz and Martin C. Rinhard

Referee:    Michael Oudshoorn
Address:    Department of Computer Science
            University of Adelaide
            Adelaide   SA   5005
            Australia

Signature:    Michael Oudshoorn

Referee Recommendations:    REJECT
 

D: Referee Comments (For Editor Only)
The paper is littered with spelling errors and this contributes to the delay in reviewing the paper.  I found that the paper is really more of a conference paper than an archival journal paper.  The applicatio n area that the authors discuss is appropriate for the journal, but too much is left unsaid, or said poorly, to make it publishable in its current form.&nbs p; For example, the paper discusses several algorithms without giving a broad overview in the main body of the text.  Details are found in the appendix at the end of the paper and the reader is forced to wade through the code to understand what the algorithm actually does.

I think that the content is publishable but only after the paper has undergone a substantial revision - more than I am able to elaborate in this review.  For this reason I have recommended that the paper be rejected at this stage and the authors ought to be encounraged to revise the paper and resubmit it for refereeing again.
 

E. Referee Comments (For Author and Editor)
Paper Number: G392        Date: 1 February, 1999

The paper addresses the issue of eliminating excessive amounts of lock acquisition and release within a parallelizing compiler.  The motivation of the work appears to be that the authors wanted to improve the performance of their compiler, yet the paper claims that the algorithms developed are more generally useful and can reduce the volume of lock aquisitio n and release in more general cases.  This claim is never substantiated.

The algorithms presented in the appendices and generally discussed in the paper work with multiple locks, but it is not clear that the compiler in question generates multiple locks.  This deficiency makes it difficult to know precisely what is happening in the experiments conducted by the authors.  It would be helpful to the reader to show some original source code, the corresponding ICFG before lock elimination etc and after lock elimination is completed.  This confusion stems in part from the text at the top of page 32 of the manuscript where it the reader is lead to believe, or may interpret the text as such, that the compiler only uses a single lock.  If this is indeed the case, then the compiler and the test cases discussed do not fully exercise the algorithms presented by the authors.  As a result, the reader may not be convinced that the algorithms have been fully tested and demonstrated to function in the presence of multiple locks.  This is important given that the paper goes to great pains to claim that it will work with multiple locks when the algorithms are discussed.

Page 13 of the manuscript gives some figures indicating how the abstractions appliced reduce the size of the ICFG.  It is unclear what the authors mean when they say "to reduce the size of the ICFG from as low as 25% to a maximum of 92% with an average of 57%".  In comparison to what - the original ICFG?  i also do not understand how to interpret the claim "from as low as 25%".

The discussion on lock movement is awkward for the reader as it becomes clear at an early stage that moving locks as discussed leads to excessive serialisation of the code if the author is not carefull.  It is not until the reader fights their way through to the discussion on false exclusion policies (page 21) that the matter is resolved (partially).&nbs p; It is only partially resolved since the reader is never told the size of the critical sections in the bounded policy wven though this policy is used in the experiments.

Page 23 explains the reachability tree for release and acuire nodes.&nbs p; This discussiion is unclear because the reader is referred to the corresponding figures and left to deduce what is happening.  The obvious question is why does a call and return node seem to inhibit the growth of the reachabili ty tree in the case of release and acquire nodes respectively?  This question is not addressed by the paper.

Finally, the experiments conducted are interesting, but a very small sample space.  It is not clear if the results obtained are representative.   Some simulation studies where artificial ICFG's are produced and lock movement and elimination performed prior to "execution" would allow some trends to be discovered.  For example, the reader is left with the feeling that it is the frequency with which locks are aquired and released that is the key issue, and it is really the amount of looping within a program that determines any improvement gain that might be observed.  What is the critical value here?  How often does the program need to loop before any benefits are seen?  Is there a relationship to the amount of computation that takes place inside the critical sections that is important?   How does communication between parallel computational elements affect things?&n bsp; I would prefer to see the paper address such questions.  This would make the paper broader and, therefore, appeal to a larger readership.
 

F. Presentation Changes

Title Changes:    None

Abstract Changes:    Providing as much detail as you have in the abstract regarding the experimental results of the algorithm was of little interest to me as I started to read the paper.  I would rather see the abstract tell me what the paper is about and what the general outcome is rather than having a third of it devoted to telling me about the experimental results at a time when I do not even know what the experiments are or what is being compared in order to claim a performance improvement.

Reference Changes/Additions:    None required.

Other Comments (Grammar etc):    The paper is littered with spelling errors, typographical errors, sentences which commence with conjunctions and the like.  I seriously doubt that the paper was proofread before submission.  As an exmaple, consider page 28 of the manuscript.&nbs p; Line 7 reads "exists synchronisation free path" and it should be "exists a synchronisation free path".  Line 10 reads: "the flow of control for the case of a release", and it should be "the flow of control in the case of a release node".  Line 10-11 reads "Because rechability [sic] trees"; the sentence should not start with the word "Because" and there is no excuse for mis-spelling reachability (and it is not the only place it is mis-spelt).  The word "because" is used several times to start sentences.  Line 15 reads: "the discussion and avoid pathological algorithmic cases we normalize", it should read "the discussion we avoid pathological algorithmic cases, we normalize".  However, this is hardly an improvment since the use of personal pronouns such as "we" are best avoided in good scientific writting.  Line 18 reads: "These simplification account" and it should be "These simplifications account".

If we consider page 29 of the manuscript, we find the following problems.  Line 2-3 reads "node it defines a clearly empty critical section".  This is probably better worded as "node it clearly defines an empty critical section".  Line 6 reads: "for a possible lock eliminatio n" which is better written as "for possible lock elimination".  The same problem occurs on line 7.  Line 9 reads: "In this normalized form of the ICFG the upper bound" and it should be: "In this normalized form of the ICFG, the upper bound".  Line 10 gives a measure of the copmlexity of the elimination algorithm without explanation.  if you are not going to explain it to the reader, why bother stating it?  You don't even give the reaer the chance to verify that it is correct.  The final 3-4 lines of the page are not clear.  They need to be rewritten so that you message is clearly conveyed to the reader and they are not required to second guess what you might mean.  Once again, explain the complexity figures claimed.

Page 24 has the following spelling errors, in addition to problems similar to that described above: "skratch", "rechability" and "reacheability".< /tt> - --------------F80E6030E7720525319DC2C0-- ------- End of Forwarded Message