Writing to the bsp-all e-mail group on Wednesday 10 April, 1996, Bill McColl said:
Colleagues,
I think we are now in a good position to proceed to Stage 2 of the BSPWW standardisation process. In Stage 1 the aim was simply to allow everyone to express their general views on the standardisation process. To some onlookers, it appeared that there were huge differences of opinion within what is still a relatively small community. I saw Stage 1 quite differently. It seemed to me that there was almost universal agreement that:
(a) Standardisation is essential, desirable and feasible.
(b) The standard must include bulk synchronous message passing and should probably include some form of bulk synchronous remote memory access.
(c) It should be a library for use with standard sequential languages such as C and Fortran. It should not involve language preprocessing.
(d) It should deal with static, stack and heap allocated data, and should be applicable to heterogeneous environments.
Jon Hill and I put out our initial draft in order to stimulate discussion. We recognised, of course, that few people would use up bandwidth to post responses which said "I agree that x is a good idea", while many would immediately come forward with "I don't like y". I think it has served its purpose quite well. We have had a number of thoughtful and constructive responses from the worldwide BSP community.
To keep to our tight schedule (complete specification by end April) I think we must now rapidly move forward to Stage 2 in which we aim to produce a sensible synthesis of the ideas proposed. To that end, Jon and I have been working closely with the Harvard BSP Group and the Green BSP Team on producing a major reworking of the original proposal. A rough draft of this is now available. The title, authors and table of contents of the new proposal are given below along with ftp addresses from which it can be obtained.
If you would like to contribute to the standardisation process then please read through it and post any comments or suggestions you may have, either to the mailing list or directly to me if that seems more appropriate. Since the volume of postings in Stage 1 strained the patience of some, it would be warmly welcomed if everyone would make their points as succinctly as is reasonable. In that way we should maintain the maximum level of interest within the community.
Bill
The proposal is available via WWW as a compressed postscript file from:
http://www.bsp-worldwide.org/standard/bspww_proposal2_a4.ps.Z Compressed A4 postscript pages
http://www.bsp-worldwide.org/standard/bspww_proposal2_letter.ps.Z Compressed Letter sized postscript pages
Or by ftp from Harvard:
ftp://ftp.das.harvard.edu/pub/bsp/bspww_proposal2_letter.ps.Z Compressed Letter sized postscript pages
.. or from Oxford:
ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Bill.McColl/bspww_proposal2_a4.ps.Z Compressed A4 sized postscript pages
or
ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Bill.McColl/bspww_proposal2_letter.ps.Z Compressed Letter sized postscript pages
1. Introduction
1.1. BSP programming languages and libraries
1.2. The BSP communication spectrum
2. Proposal
2.1. Creating BSP processes
2.2. Superstep synchronisation
2.3. Bulk synchronous remote memory access
2.3.1. Making local areas available for remote use
2.3.2. Buffering semantics of DRMA operations
2.3.3. Putting data into a remote location
2.3.4. Getting data from a remote location
2.4. Bulk synchronous message passing
2.4.1. Setting the tag size
2.4.2. Sending a message
2.4.3. Procedures for receiving a message
2.4.4. A lean method for receiving a message
2.5. Raising an error and halting
2.6. Timing routine
3. Rationale
3.1. Simulating dynamic spawning of processes
3.2. Why there is no subset synchronisation
3.3. Buffering of DRMA operations
3.4. Buffering, safety and efficiency
3.5. Bulk synchronous message passing
A. Collective communications
Go to BSP Worldwide News Page
Please send comments to Bob McLatchie
Last modified May 22, 1996