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. Vitorio. 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 yourselfFWIW, 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.Hi, At the moment, I think that Boost.MPI only supports MPI1.1, and eventhen, some additional work may be done, at least regarding the complexdatatypes. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/Blogs: http://matt.eifelle.com and http://blog.developpez.com/? blog=92LinkedIn: http://www.linkedin.com/in/matthieubrucher _______________________________________________ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users-- Jeff Squyres Cisco Systems _______________________________________________ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: Ceci est une signature électronique PGP
