Subject: Re: Request to review a paper C499 From: "Ron Brightwell" Date: Wed, 13 Jun 2001 18:24:08 -0600 (MDT) To: fox@csit.fsu.edu > > Bill Camp suggested that you might be able to referee a paper for the > journal Concurrency and Computation: Practice and Experience. Any help you can give > would be appreciated My referee report is below. Thanks for the opportunity to help with reviews. -Ron REFEREE'S REPORT Concurrency and Computation:Practice and Experience --------------------------------------------------------------------------- A: General Information Please return to: Geoffrey C. Fox Electronically Preferred fox@csit.fsu.edu Concurrency and Computation: Practice and Experience Computational Science and Information Technology Florida State University 400 Dirac Science Library Tallahassee Florida 32306-4130 Office FAX 850-644-0098 Office Phone 850-644-4587 but best is cell phone 3152546387 Please fill in Summary Conclusions (Sec. C) and details as appropriate in Secs. D, E and F. B: Refereeing Philosophy We encourage a broad range of readers and contributors. Please judge papers on their technical merit and separate comments on this from those on style and approach. Keep in mind the strong practical orientation that we are trying to give the journal. Note that the forms attached provide separate paper for comments that you wish only the editor to see and those that both the editor and author receive. Your identity will of course not be revealed to the author. C: Paper and Referee Metadata * Paper Number Cnnn: C499 * Date: June 13, 2001 * Paper Title: "Data Movement and Control Substrate for Parallel Adaptive Applications" * Author(s): Jeffrey Dobbelaere, Kevin Barker, Nikos Chrisochoides, and Demian Naves, Keshav Pingali * Referee: Ron Brightwell * Address: Sandia National Labs PO Box 5800 Albuquerque, NM 87185-1110 bright@cs.sandia.gov Referee Recommendations. Please indicate overall recommendations here, and details in following sections. 2. accepted provided changes suggested are made D: Referee Comments (For Editor Only) E: Referee Comments (For Author and Editor) Overall this is a good paper, and the work addresses an important aspect of high-performance communication for parallel applications and machines. However, I believe that it is lacking a few important pieces that need to be added in order to make it complete. Most of the complexity in message passing occurs on the receiving side. This is reinforced in the paper by the descriptions of how to implement DMCS under MPI and LAPI. Most of the important issues, such as how the receive side handles message ordering, message buffering, and polling strategies, are described in detail. However, the performance results do not include any data specifically related to the receive side. The paper makes several references to a DMCS polling operation that the main application thread must call in order for DMCS handlers to execute. The polling operation is an important part of the DCMS implementation, but one can't tell from the paper exactly how it should be used. Does the main thread simply call the polling function continuously like in an event driven X program? Or is it something that needs to be periodically called by the application? There should be something that describes the polling function and its use in greater detail. It's also unclear from the performance measurements exactly what the receive side is doing. The overhead of the asynchronous send-side operations is interesting, but I would think that ultimately the delivery of data and/or remote function invocation are important things to measure as well. It seems like the LAPI implementation would certainly perform better than the MPI probing implementation on the receive side, but there should be some performance numbers to back that up. The other piece that's missing is a related work section. There are several programming models and systems based on one-sided communications -- Cray SHMEM, Global Arrays, Cooperative Data Sharing, MPI-2, etc. An overview of how DMCS compares and contrasts with these systems is needed. It appears as though DMCS pre-dates some of these and specifically addresses areas that they don't. It would be beneficial for this paper to clarify and qualify what distinguishes DMCS from these other projects. F: Presentation Changes In Figures 6 and 7, the line plotting "DMCS time" is hardly visible. Likewise in Figure 8 for "LAPI time". For Figures 6 and 7, the nearly invisible line plot and the scale of the graph make it hard to decipher. The tables of data would be much clearer and easier to understand if they were presented in microseconds or milliseconds rather than in seconds using scientific notation. The statement regarding "Cluster CoNTroler" on page 4 should cite a reference and possibly describe what exactly it is. On page 7, MPI is referred to as a "common message passing software package", which is an incorrect description. Care should be taken when discussing MPI as a standard as opposed to MPI as an implementation.