I think you face a common trade-off:

- use a well-established, debugged, abstraction-rich library
- write all of that stuff yourself

FWIW, I think the first one is a no-brainer. There's a reason they wrote Boost.MPI: it's complex, difficult stuff, and is perfect as middleware for others to use.

If having users perform a 2nd step is undesirable (i.e., install Boost before installing your software), how about embedding Boost in your software? Your configure/build process can certainly be tailored to include Boost[.MPI]. Hence, users will only perform 1 step, but it actually performs "2" steps under the covers (configures+installs Boost.MPI and then configures+installs your software, which uses Boost).

FWIW: Open MPI does exactly this. Open MPI embeds at least 5 software packages: PLPA, VampirTrace, ROMIO, libltdl, and libevent. But 99.9% of our users don't know/care because it's all hidden in our configure / make process. If you watch carefully, you can see the output go by from each of those configure sections when running OMPI's configure. But no one does. ;-)

Sidenote: I would echo that the Forum is not considering including Boost.MPI at all. Indeed, as mentioned in different threads, the Forum has already voted once to deprecate the MPI C++ bindings, partly *because* of Boost. Boost.MPI has shown that the C++ community is better at making C++ APIs for MPI than the Forum is. Hence, our role should be to make the base building blocks and let the language experts make their own preferred tools.

On Jul 7, 2009, at 5:03 AM, Matthieu Brucher wrote:

> IF boost is attached to MPI 3 (or whatever), AND it becomes part of the > mainstream MPI implementations, THEN you can have the discussion again.


At the moment, I think that Boost.MPI only supports MPI1.1, and even
then, some additional work may be done, at least regarding the complex

Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
users mailing list

Jeff Squyres
Cisco Systems

Reply via email to