C328 Referee Report This is an interesting paper which I recommend for publication with some clarifications. I did not understand the discussion of page 14 and how one translated table 2(and its analogs) into a performance model. What is the analytic dependence of performance on (1/a,1/b) and complexity formula given in middle column of table 2! It would be helpful to estimate the time required to develop the two models - full phase and simple algebraic complexity. Further can you comment on the scaling of this model development time to (other) "real" problems. Dear XYX, We enclose a referee report on your paper: C328: We also think that this paper should be published but hope that you can make the suggested changes. Please give the Web reference to the full technical report and omit the appendix in the version for publication. Also we would like you to include a memo describing the changes in the revised version. We thank you for your interest in our journal Concurrency: Practice and Experience C329 Referee Report This paper is interesting but needs some improvements before publication. 1) The third paragraph in section 1 (page 1) seems out of place. Either elaborate, delete or move (to where paper referenced later). 2) The Meiko machine used is obsolete. Please indicate how your results might look on more modern machines such as the IBM SP2 or CRAY T3E with different communication bandwidth and latency. 3) (related to 2)) Please discuss (no runs needed) how you expect your results to scale to larger problems and larger machines for both sequential and parallel performance. 4) The last paragraph (top of page 15) seems pretentious and I suggest removing it. Focus on the parallelization of your algorithm. There are others who have broader experience who can make such global comments with more authority. Dear XYZ, We enclose a referee report on C329: We expect to be able to publish a paper that is revised according to the referee's suggestions. Please include a memo describing your changes with the revised paper. We thank you for your interest in our journal Concurrency: Practice and Experience. C330 Referee Report This is an interesting well written paper which should be published. The abstract suggests a pure benchmarking paper but this does not seem to describe the essential contribution well. This rather appears to me to be a new approach for better selecting optimal algorithms through the analysis of lambda and alpha. I suggest that the authors make the purpose and contribution of the paper clearer in both abstract and introduction. Dear XYZ, We enclose a referee report on C330: We would be pleased to publish a revised paper addressing the point raised by the referee. Please include a memo describing your changes with the revised paper. We thank you for your interest in our journal Concurrency: Practice and Experience. C331 Referee Report This is a thorough clear paper giving substantial deep insight into the factors affecting parallel performance of simulation codes. I have some concern that the results are a little misleading due to the relatively poor node performance compared to network bandwidth of the Paragon. This paper would be more valuable if the detailed Paragon study was complemented by an analysis of several machines (SP2,T3E etc.) for just one of the many cases looked at for the Paragon. Alternatively this paper could link to a Web page (such as that available for NAS and Linpack benchmarks) with broader data on more machines. Dear XYZ, We enclose a referee report on your paper C331: We agree with these comments and would be pleased to publish a paper addressing them. We look forward to a revised paper which should include a memo describing any changes. We thank you for your interest in our journal Concurrency:Practice and Experience ************ C332 is really IJMPC !!!!!!!!!!!!!!!! *************** Give a P number and send me Bernholdt report C333 Referee Report Although this is a potentially interesting paper, I suggest that the DCO project is at the wrong stage for Concurrency publication. There is a little bit of practical data in the last section but the paper is essentially theoretical. In particular there is no application motivation or testing. Thus we have no way of judging the significance of the practical results which are confined to system performance. I would also like to suggest that suitable reference be made to the Legion project (Virginia) and Horus(Isis Cornell). In its current form, I recommend rejection of this paper for Concurrency and its resubmittal to a more appropriate journal. Dear XYZ, We enclose a referee report on C333: We agree with this evaluation and suggest that you either resubmit to Concurrency: Practice and Experience with a more substantial application (practical) focus or chose another journal. We thank you for your interest in our journal Concurrency:Practice and Experience C334 Referee Report This is a rather offbeat but intriguing paper. I would suggest adding a table collecting the semantics of the various synchronization primitives so that the reader can contrast and understand the differences better. Flippantly we note that children love Java as it is associated with web animation and so it clearly appropriate for solving the Santa Claus problem and I don't think kids would like to know that the defense associated ADA95 was better! More seriously, I believe that Java is now a better understood and defined and some of the caveats in the text can be removed. There are some others who have looked at Java threads for concurrency. Two that come to mind are Chandy at Caltech (giving Java functionality of his older CC++ concurrent language) and Wei Li from Rochester. Please reference such other work. Dear XYZ, We enclose a referee report on C334: We would be happy to publish a revised paper addressing the points raised. Please include a memo describing any changes in your resubmittal. We thank you for your interest in our journal Concurrency: Practice and Experience C336 Letter to Authors Dear XYZ, Thank you for your interesting paper: C336: Our referees recommend publication but note that the abstract is rather long and that one might also wish to reference the work on groups built into the parallel processing communication standard MPI. We also note that although in general nicely written, there are a few grammar glitches which would be caught by a careful proof reading which we suggest you perform. We will be honored to publish such a revised paper and look forward to receiving it. We thank you for your interest in our journal Concurrency:Practice and Experience C337 Referee Report First I note an embarrassing duplication of material between sections IV.1 and IV.3. Further although this paper covers an interesting area, I cannot recommend publication for a more serious reason. Namely the machines used are totally obsolete. Note that today's PC's get a factor of 100 better performance than your nodes (using Transputer megaflop rate that you quote). I suspect that moving to newer designs will impact your conclusions as modern machines will be more sensitive to optimizing communication as they have relatively higher latency and lower bandwidth. C337 Letter NOTE that I do not have Ziavras Letter **************************** Please send to me so I can double check Dear XYZ, We enclose two referee reports on C337: We agree with one referee that the work must be presented in the context of data and its analysis for more architectures. Thus we cannot publish the submitted paper but encourage you to resubmit the extended version using T3E/SP2/Origin 2000 class machines. We thank you for your interest in our journal Concurrency:Practice and Experience C338 Referee Report This is an interesting paper which made me realize for the first time that using threads was harder than I thought. Any further comments on requirements on thread functionalities to ease implementation of LPVM like systems would be interesting. I was unclear if message passing was implemented by data movement (on an SMP) or by setting pointers in a shared memory. I would have thought latter was most natural and would get (unlike table 2) better performance for thread version of PVM. C338 Letter We enclose two referee reports on C338: We agree that this paper is an important contribution and hope that you can make the elaborations suggested by the referees. We will then approve the paper for publication without further ado. Please include a memo describing your changes with the revised paper. We thank you for your interest in our journal Concurrency:Practice and Experience