[Mpi-forum] Discussion points from the MPI-<next> discussion today

[N.M. Maclaren]

On Sep 23 2012, Jed Brown wrote:
>
>Your insistence on inability to implement certain features in vanilla C99
>is a red herring. Every MPI implementation has a huge number of configure
>tests for architecture-specific features. Since nobody cares about writing
>an MPI implementation in vanilla C99, your perseverance on that continues
>to be a red herring.

You really are confused.  It has damn-all to do with the dialect that
MPI is written in, and all to do with the language that the program is
written in.  You may be happy to write and use programs that deliver
unrepeatable wrong answers with low probability on some systems, or
write totally non-portable programs, but most MPI users are not.

> Before that was learnt the
>> hard way, they were as unreliable as most shared-memory codes are today.
>
>It sounds like you're implying that necessity of memory barriers was
>discovered by trial and error. Maybe some people write code that way, but
>those are the same people writing buggy serial software. Shared memory
>software that matters (e.g., Linux and PostgreSQL) was engineered to be
>correct. This is not a new thing.

Jesus wept!  I wasn't talking about the 1980s, but the 1960s.  It was
learnt the hard way.

>> MPI does not and cannot impose such constraints, and this is why using
>> passive one-sided communication or user-defined operators in MPI_Ireduce
>> and MPI_Irecv_reduce is undefined behaviour in all of the languages it
>> supports.  That is fixable only by specifying that the user-defined
>> operator is called either in the initial call or the wait.
>
>1. Even within your world, it can be in a wait/test, an unrelated send,
>etc. Those modes are useful.

That can be done only if you impose some OTHER constraints on the use
of the buffers, which MPI currently does not do.  I know how to do it,
in both Fortran and C99, but I doubt that you do.  The issues for
MPI_Ireduce and MPI_Irecv_reduce are far subtler, and I am not even
going to try explaining them until you understand the simpler one.

Enough is enough.


Regards,
Nick Maclaren.