[Review][MPI] Boost.MPI Review
Hi Everyone, I have been lurking a while already, and I'm doing my first review of a Boost library being proposed for inclusion. I would like to say that I'm pretty new at this review thing, and I'm trying to learn about the way it's being done as fast as I can. I certainly hope this review brings out a few points that may make sense, and I also hope the library authors (Doug Gregor and Matthias Troyer) would take the time to consider the points in this message. So here goes the review: Explicitly State My View: YES, I think it should be accepted into Boost. Details and suggestions below. - What is your evaluation of the design? The design is pretty straightforward, and easy to understand even for the novice C++ developer -- which is a welcome characteristic IMO. I certainly appreciate the relatively few headers, and "fat classes" that group together the related methods and data -- citing the Communicator and the Environment classes. - What is your evaluation of the implementation? Given the very well-thought out and straightforward design, I have some reservations about the interface specifically with the Communicator class. Having been reading up on type-safe interfaces, the main issue I see is the relative ease in confusing the order of the fields/types in communicator::send/receive/isend/ireceive arguments: template <typename T> void send(int, int, const T &) const ; The above line doesn't say anything about what the first int is, and what the second int is -- and it's fairly easy to confuse which one is the rank and which one is the tag. A suggestion I would make is either to utilize Boost.Parameter to come up with something like: mpi::communicator c; std::string str("Hello, World!"); c.send(tag=0, rank=1, value=str); c.send(rank=1, tag=0, value=str); c.send(value=str, rank=1, tag=0); Or if that introduces too many issues regarding performance (I'm not sure), then perhaps using some wrappers and overloads for type safety will be useful to allow the following: mpi::communicator c; std::string str("Hello, World!"); c.send(mpi::tag(0), mpi::rank(1), mpi::value(str)); c.send(mpi::rank(1), mpi::tag(0), mpi::value(str)); c.send(mpi::value(str), mpi::tag(0), mpi::rank(1)); The two approaches above would IMO make the library more "idiot-proof" or "newbie-friendly" and certainly (though more tideous to use) considerably type-safe and verbose. - What is your evaluation of the documentation? The web documentation contains certain characters marked and displayed as question marks not present in the PDF version. There are also a handful of typographical errors, though nothing a quick copy-editing would not be able to fix. There is also a need to revise the introduction, and move the in-depth details in a separate section. The Introduction section already talks about a lot of the specifics, when a user reading the documentation would be more concerned really just about what Boost.MPI is rather than the details of how it implemented certain things. I can elaborate in a separate email, which I think I should probably do. - What is your evaluation of the potential usefulness of the library? I think this library will be very useful indeed having been exposed to the mess that is the C implementation of the MPI standard. I've personally tried to tackle with issues like sending and receiving strings and user created data structures (C structs) and the MPI methods are not very helpful nor intuitive in their current form (even MPI 2.0). Being able to introduce an object oriented view of the parallel computing application by encapsulating in objects the MPI interface and adding terse yet expressive interfaces will definitely be helpful in the field. In my experience with academic use of parallel computers (though how very little exposure I have here in the Philippines of that), the biggest barrier to entry is the programming interface. The MPI API's require a lot of patience from even the most experienced C or C++ programmers, and the Boost.MPI interface is a welcome implementation on the change to making it make more sense. Since most of the people I've talked to are in the academe, it would be easier to 1) teach MPI programming with Boost.MPI 2) use the MPI especially for non-computer scientists (Physicists, Mathematicians, Engineers) that might not have the same exposure to C or C++. Since the Boost.MPI interface makes the programs considerably more readable, it should allow for lowering the barrier to entry into parallel and high-performance computing. - Did you try to use the library? No, since I don't have the required libraries and tools (Boost CVS, LAM/MPI 7 for Windows) set up yet. However, I intend to use this library in its current form most probably post-review regardless of the review outcome, and even try to contribute in any way I can (docs, patches, etc.) - How much effort did you put into your evaluation? I have read the documentation, and looked at the design primarily of the library -- and focused on the interface provided. Since I have not had the time nor means for testing the library at the moment, I cannot comment on the implementation especially in terms of the effects in runtime performance and the compile time characteristics. Because of this, I have reserved my comments until the time I can scrutinize the implementation and how it relates to the MPI implementation I shall use. - Are you knowledgable about the problem domain? I have used the MPI C API (LAM/MPI Implementation) in more than one instance in an academic setting (translation: school project on a prallel genetic algorithm implementation for finding the optimal tour in a 100 city travelling salesman problem, thesis on adaptive dynamic allocation algorithm in heterogeneous non-dedicated computing clusters). I would like to think I am knowledgable about the problem domain with ample exposure to the MPI C API (though with MPI 2.0). -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
The above line doesn't say anything about what the first int is, and what the second int is -- and it's fairly easy to confuse which one is the rank and which one is the tag. A suggestion I would make is either to utilize Boost.Parameter to come up with something like:
mpi::communicator c; std::string str("Hello, World!"); c.send(tag=0, rank=1, value=str); c.send(rank=1, tag=0, value=str); c.send(value=str, rank=1, tag=0);
Great idea!
Or if that introduces too many issues regarding performance (I'm not sure)
I think our tests have demonstrated that Boost.Parameter has no measurable runtime performance impact, [or maybe even a positive one ;-)] -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hmmm - one could also use BOOST_STRONG_TYPEDEF to define types so that one would write: mpi::communicator c; std::string str("Hello, World!"); c.send(tag(0), rank(1), str); ... or tag t(0); rank r(1); c.send(t, r, str); Just and idea. Robert Ramey David Abrahams wrote:
"Dean Michael Berris" <mikhailberis@gmail.com> writes:
The above line doesn't say anything about what the first int is, and what the second int is -- and it's fairly easy to confuse which one is the rank and which one is the tag. A suggestion I would make is either to utilize Boost.Parameter to come up with something like:
mpi::communicator c; std::string str("Hello, World!"); c.send(tag=0, rank=1, value=str); c.send(rank=1, tag=0, value=str); c.send(value=str, rank=1, tag=0);
Great idea!
Or if that introduces too many issues regarding performance (I'm not sure)
I think our tests have demonstrated that Boost.Parameter has no measurable runtime performance impact, [or maybe even a positive one ;-)]
"Robert Ramey" <ramey@rrsd.com> writes:
Hmmm - one could also use BOOST_STRONG_TYPEDEF to define types so that one would write:
mpi::communicator c; std::string str("Hello, World!"); c.send(tag(0), rank(1), str); ... or tag t(0); rank r(1); c.send(t, r, str);
Just and idea.
The downside of that approach is that you still have to remember the parameter order. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sep 6, 2006, at 5:10 PM, Dean Michael Berris wrote:
- What is your evaluation of the implementation?
Given the very well-thought out and straightforward design, I have some reservations about the interface specifically with the Communicator class. Having been reading up on type-safe interfaces, the main issue I see is the relative ease in confusing the order of the fields/types in communicator::send/receive/isend/ireceive arguments:
template <typename T> void send(int, int, const T &) const ;
The above line doesn't say anything about what the first int is, and what the second int is -- and it's fairly easy to confuse which one is the rank and which one is the tag. A suggestion I would make is either to utilize Boost.Parameter to come up with something like:
mpi::communicator c; std::string str("Hello, World!"); c.send(tag=0, rank=1, value=str); c.send(rank=1, tag=0, value=str); c.send(value=str, rank=1, tag=0);
I like this a lot. I expect it will be very easy to do with with the Parameter library :)
- What is your evaluation of the documentation?
The web documentation contains certain characters marked and displayed as question marks not present in the PDF version. There are also a handful of typographical errors, though nothing a quick copy-editing would not be able to fix.
Ugh. I'll regenerate the documentation on a different machine to get rid of the question marks.
There is also a need to revise the introduction, and move the in-depth details in a separate section. The Introduction section already talks about a lot of the specifics, when a user reading the documentation would be more concerned really just about what Boost.MPI is rather than the details of how it implemented certain things.
You are right.
I can elaborate in a separate email, which I think I should probably do.
That would be greatly appreciated. Thanks for the review! Cheers, Doug
Douglas Gregor wrote:
On Sep 6, 2006, at 5:10 PM, Dean Michael Berris wrote:
...
mpi::communicator c; std::string str("Hello, World!"); c.send(tag=0, rank=1, value=str); c.send(rank=1, tag=0, value=str); c.send(value=str, rank=1, tag=0);
I like this a lot. I expect it will be very easy to do with with the Parameter library :)
I also like this, and add my voice to supporting it. John Phillips
participants (5)
-
David Abrahams -
Dean Michael Berris -
Douglas Gregor -
John Phillips -
Robert Ramey