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
>> 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
>> Information System Engineer, Ph.D.
>> Website: http://matthieu-brucher.developpez.com/
>> Blogs: http://matt.eifelle.com and http://blog.developpez.com/?
>> LinkedIn: http://www.linkedin.com/in/matthieubrucher
>> users mailing list
> Jeff Squyres
> Cisco Systems
> users mailing list
- application/pkcs7-signature attachment: smime.p7s