[cfe-commits] [PATCH] Compile-time MPI_Datatype checking, type arguments in attributes
Dmitri Gribenko
gribozavr at gmail.com
Mon Feb 13 04:03:28 PST 2012
On Mon, Feb 13, 2012 at 3:15 AM, Chandler Carruth <chandlerc at google.com> wrote:
> On Sat, Feb 11, 2012 at 10:09 AM, Dmitri Gribenko <gribozavr at gmail.com>
> wrote:
>> int MPI_Send(void *buf, int count, MPI_Datatype datatype, int dest,
>> int tag, MPI_Comm comm);
>
> Before I look in much closer detail at this proposal, I'd really like to
> understand why the solution to the lack of type safety in this C API isn't
> to use a C++ API.
>
> We have languages that provide strong type safety guarantees and high
> efficiency. It would be a shame to design and layer a type safety system on
> top of a C API like this rather than use those languages.
I agree that typesafe C++ APIs should be the future. But current
reality is a bit different.
1. MPI C bindings and MPI Fortran bindings are standardized. MPI C++
bindings are not typesafe and are deprecated. Boost.mpi is not
standardized. Boost.mpi is not bindings (it is not a 1:1 mapping of
MPI features).
2. Even if tomorrow a typesafe API is standardized, MPI C bindings are
not going to disappear or be deprecated for at least ~10 years.
3. There are existing codebases that use MPI C bindings and need to be
maintained (but nobody will rewrite them if we invent typesafe MPI
bindings).
4. Current solution in the form of Boost.mpi is not appropriate for everyone.
4.1. Boost.mpi does not expose all MPI features [1] (most notable
being MPI_*v functions and one-sided communication).
4.2. Boost.mpi is not a drop-in replacement for MPI C bindings. One
might need to switch from C to C++. It might be required to wrap your
data into new data types to send it in a non-default way (for example,
to send a column of a double* matrix in row-major format).
[1] http://www.boost.org/doc/libs/1_48_0/doc/html/mpi/tutorial.html#mpi.c_mapping
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
More information about the cfe-commits
mailing list