Subject:
Re: Request to review a paper C499
From:
"Ron Brightwell" <rbbrigh@valeria.mp.sandia.gov>
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.