|
Adoption of Proposal as an International Industry Standard
There is a clear vote in favour of adoption, but there are a number of dissenting voices. Some of the dissenters give conditional approval, others reject the adoption of the BSPlib proposal outright. Detailed reasons for both responses are given below.
Reasons given for conditional acceptance (Yes, provided the following changes are made ...)
- The introduction of a more flexible control especially for task parallelism
- I would like to see more thoughts on the following issues: 1. bsp_init/bsp_begin: is it possible to make it simpler, or merge the two to make it more concise? 2. is high performance put/get/move really worth it? does it make comm/sync rules more complicated? 3. I have never used message-passing primitives, and am not 100% convinced that BSMP is really necessary.
- If there is some compromise between BSMP and DRMA.
- support for dynamic process creation
- Removal of the 'tag' portion of data packets from the message passing interface. This seems like an unnecessary complication of what would otherwise be a VERY simple interface.
|
Reasons for not adopting are:
- BSPlib does not have an adequate Fortran interface. It is an inefficient implementation of BSP principles. MPI-2 largely removes the need for BSPlib (write BSP programs in a subset of MPI-2 instead). The definition of a small BSP library as a thin API on top of MPI-2 might be worthwhile as a teaching tool, but is formally unnecessary since MPI-2 can be used for BSP programs directly.
- For an international standard that suits many types of industry, I could imagine that the functionality of BSP is somewhat limited at the moment.
- Perhaps some more experience is necessary..but I am not sure. I personally find the DRMA intimidating but I don't use it. On the other hand, I don't think anyone else uses the message passing portion at all..other than the Green BSP guys like myself.
- The only meaningful standard is the 'standard of practice', as determined by the number of users. It depends on whether BSPlib wins its battle over its direct competitors (e.g., MPI).
- BSPlib is much too complicated. The BSP model offers a tremendous advantage of simplicity compared to existing standards such as PVM and MPI, but BSPlib threatens to throw away the one characteristic which makes BSP attractive to real application programmers. The BSPlib specification appears also too complicated to implement simply, if the Oxford Toolset implementation (27000+ lines, 90+ files) is a representative example.
- Mixing message passing with DRMA will make it very difficult for the average parallel software developer to see why he or she should be interested in BSP. There's already a standard for message passing, with genuine widespread usage and support.
- It is much too early to be standardising on a single pattern of BSP programming. We need many more experiments of different BSP styles, language-based as well as library-based, and we need solid scientific research results comparing the performance and complexity of different approaches so that software engineers can make a choice based on facts rather than marketing hype.
|
|
| Most Important Feature |
Least Important Feature |
There were several votes for BSP Message Passing, and an equal number for DRMA. One vote for both. Other features mentioned:
- A simple definition and a simple cost model
-
Profiling Tools.
- Automatic optimisation where the user does not have to worry about contention or combining smaller messages into larger ones.
-
Few primitives, clean interface, easy to use
- Portability
|
There were several votes for BSP Message Passing, and an equal number for DRMA. Other features deprecated:
- Call-graph profiling ( can't get it to work )
-
High Performance" primitives : bsp_hp[put|get|move] (several mentions)
- Performance profiling
But two people said "It is difficult to find something I could do without: BSPlib contains just essential, basic primitives" and two said "I don't know (yet)".
|
|
Facilities offered in Proposal
In assessing the most valuable feature (and the corresponding least valuable) it is clear that the world divides between those who use and value BSP Message Passing and those who do not. For the former BSMP is clearly the best feature, for the latter it is DRMA. BSPlib has both, so no-one need be disadvantaged.
|
| Ease of use of the facilities
It is interesting that most people with BSPlib installed think the facilities are easy to use; some are even prepared to rate the facilities "easy" before installation.
Of course it is to be expected that those who have taken the decision to install would tend to say the facilities are easy to use. To do otherwise is to risk questioning one's judgement in taking the trouble to install and try the library. Nevertheless the voting here is clearly decisive. |
|
Range of Facilities in Proposal
As in the previous section, the voting here indicates quite decisively that users tend to think that the range of facilities has been correctly judged to match requirements.
Some changes were requested:
- Some documentation on high level collective communication routines ( bsplib_level1 ) would be useful.
- the Fortran interface is C-centric. Using byte-offset pointers is not acceptable. MPI-2 provides a much better interface.
- Synchronization of subsets of processors would be very useful/ The library should support a form of subset synchronization.
- Maybe it should be better include some frequently-used procedures.
- I wonder if there is any benefit in BSMP facility.
- consider process topolgies with high performance neighbour communications cf. BACS (from University Basel)
- I do not agree that the BSPlib specification is small. In relative terms, it has many more functions and configurable options than the Oxford BSP library, and is comparable in complexity to PVM.
|
|
