Ok, after all the considerations, I'll try Boost, today, make some experiments and see if I can use it or if I'll avoid it yet.

But as said by Raimond I think, the problem is been dependent of a rich-incredible-amazing-toolset .... but still implementing only MPI-1, and do not implement all the MPI functions main drawbacks of boost, but the set of functions implemented do not compromise the functionality, i don't know about the MPI-1, MPI-2 and future MPI-3 specifications, how this specifications implementations affect boost and the developer using Boost, with OpenMPI of course.

Continuing if something change in the boost how can I guarantee it won't affect my code in the future ? It is impossible.

Anyway I'll test it today and without it and choose my direction, thanks for all the replies, suggestions, solutions, that you all pointed to me I really appreciate all your help and comments about boost or not my code.

Thanks and Regards.

Le 09-07-07 à 08:26, Jeff Squyres a écrit :

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

users mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Attachment: PGP.sig
Description: Ceci est une signature électronique PGP

Reply via email to