[Mpi-forum] MPI Count proposal from today's meeting

[Supalov, Alexander]

PS. "Semantically cleaner", that is.

-----Original Message-----
From: Supalov, Alexander 
Sent: Friday, June 18, 2010 11:41 AM
To: Main MPI Forum mailing list
Subject: RE: [Mpi-forum] MPI Count proposal from today's meeting

Thanks. Let's agree on what we call the "short int" and the "default int". For me, "short int" is historically a 2-byte signed entity. I'm thinking of the "default int" as a 4-byte signed entity. I know there were many other approaches, but I am intentionally going with the current mainstream here. With this, do we use these terms in a comparable manner?

As to the reasons not to delve into the unsigned jungle, I agree with your arguments, especially those from your first reply. Irrespective of this, the use of the MPI_UNDEFINED in the MPI_GET_COUNT looks a little careless now that the MPI_Count may be larger than the default int (in the above understanding). We'd probably fare syntactically cleaner with the MPI_COUNT_UNDEFINED of the respective size (cf. MPI_PROC_NULL).

In some sense, I assume that the MPI_UNDEFINED was initially added to the MPI_GET_COUNT return value range out of utility consideration, like, "we already have the MPI_UNDEFINED, why not using it here, too?" It is this initial motivation, if it indeed was comparable, that may need review now.

-----Original Message-----
From: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of N.M. Maclaren
Sent: Friday, June 18, 2010 11:18 AM
To: Main MPI Forum mailing list
Subject: Re: [Mpi-forum] MPI Count proposal from today's meeting

On Jun 18 2010, Supalov, Alexander wrote:

> Thanks. I agree that use of the MPI_UNDEFINED by the MPI_GET_COUNT may 
> need additional review. Why do you think the ranks are "short int" 
> entities?

Eh?  If anyone is proposing to support processor numbers greater than
can be stored in a default integer in either Fortran or C, they need
professional help, badly!

MPI's basic design won't stand up to such scaling, for a start - indeed,
I don't know of any current or proposed design that would.  As a rather
rusty mathematician, I can think of a few plausible ones, but they are
so radical that most computer scientists would have hysterics at the
very concepts.

Also, the way that most people write MPI code won't stand up to that.
You had better not have any automatic or static arrays of that size, for
a start, because almost every compiler will crash or generate bad code
if you do.  ALL such arrays must be dynamic.


On this matter, are you SERIOUSLY thinking of making MPI_COunt unsigned?
For the other reasons I mentioned, it's a crazy idea.  I don't know how
well you know C, C++ or Fortran, but I know the first extremely well,
the last well, and the other tolerably.  The portability problems and
other gotchas are foul beyond most people's imagination - and, God help
us, they really do cause trouble in practice :-(


Regards,
Nick Maclaren.



_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.