[Mpi-forum] Fwd: MPI_Count

[Snir, Marc]

good arguments -- so that would suggest using MPI_COUNT and specify that this is a 64 bit integer. You may use a more descriptive name -- e.g. MPI_INT64, or something like this.

On Jan 26, 2010, at 7:19 AM, Jeff Squyres wrote:

Here's Nick's reply.  Thanks Nick!

Begin forwarded message:

From: "N.M. Maclaren" <nmm1 at cam.ac.uk<mailto:nmm1 at cam.ac.uk>>
Date: January 26, 2010 8:15:24 AM EST
To: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com<mailto:jsquyres at cisco.com>>
Cc: "Darius Buntinas" <buntinas at mcs.anl.gov<mailto:buntinas at mcs.anl.gov>>, "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org<mailto:mpi-forum at lists.mpi-forum.org>>
Subject: Re: [Mpi-forum] MPI_Count


On Jan 26 2010, Jeff Squyres wrote:
>On Jan 25, 2010, at 4:33 PM, Darius Buntinas wrote:
>
>> >> There are many different ways where<stdint.h> integers cause
>> >> portability, efficiency and other problems. Inter alia, the current
>> >> revision of C is thinking of changing them in ways that could be
>> >> incompatible with old code, and they are semantically incompatible
>> >> with Fortran and many other languages in several respects.
>
>> Did the person state what the portability issues with int64_t could be?
>>   Is there a C "basic type" that would be compatible with a fortran
>> INTEGER*8?  BTW, we already added stdint datatypes to MPI 2.2.
>
> Nick -- most people thought using "MPI_Count" as a type is fine, but I,
> too, am curious about Darius' question (above). Could you comment? (if
> you're not a member of the mpi-forum list, I can forward your reply)

Certainly.  Please forward this, if relevant.  But let me start with
a subsidiary point.

On political grounds, I accept that there is no alternative but to add
the major <stdint.h> names, but there is no realistic way that MPI can
support all of <stdint.h>.  Inter alia, it is an open-ended
specification, and the complete set of types and their semantics is not
even implementation-defined.

Here is a subset of the reasons that <stdint.h> is ill-defined (which is
a major obstacle to portability) or explicitly non-portable - references
are to C99:

Most people believe that int8_t, uint8_t, int16_t, uint16_t int32_t,
uint32_t, int64_t, uint64_t, intptr_t and uintptr_t are required, and
they are certainly the most commonly used names.  They are wrong, and
those names are optional, for very good reasons (see 7.18.1.1#3 and
7.18.1.4#1).  Does MPI specify them as required or optional?  It should
do the latter.

The existence of intptr_t, uintptr_t, intmax_t and uintmax_t all block
implementations from extending their pointer and integer semantics
upwards compatibly (see 7.18.1.4 and 7.18.1.5).  The former is a very
serious issue, as experience has shown.  But pointers are now and
henceforth all 64 bits, right?  That's doubtful.  That blocks
implementations from extending them to allow 'capability' pointers
(e.g. IBM i series, a.k.a. i5/OS or OS/400), and might block
thread-specific pointers (i.e. with a thread id as part of the pointer
value).  Some experts think that the latter are essential for the
computers of 2020 and onwards.  I should HOPE that MPI is planning
on that timescale.

It is undefined whether the type names are typedefs of any of the basic
integer types, other standard integer types (e.g. size_t), other
extended integer types or are new integer types, even if they have
identical characteristics (see 6.2.5#4, 6.3.1.1#1 and 7.18,
especially #1, #4 and footnote 215).  Because typedefs are synonyms and
new types are not, this affects the promotion and type compatibility
rules and hence whether (at least some) programs AND SPECIFICATIONS are
portable.  MPI needs to be VERY careful that it doesn't trip across this
one by accident, because it involves parts of the C standard that few
people ever reach.

Exact-width integer types (7.18.1.1) are a mess.  #1 says that they
must have a two's complement representation and no padding bits, but
#3 requires them to be specified if an implementation has any integers
of the specified width (see 6.2.6.2#6).  They were claimed to be needed
for external data formats, but that's largely pointless without
specifying endianness and (more seriously) overflow semantics (see
6.2.6.1#5 and 6.2.6.2#2).  There are already several incompatible views
on what their specification means.  If that ever reaches the point that
the problem can't get swept under the carpet, expect a religious war.

Following on from that, even C's basic model is a subset of 'pure
binary' with two's complement and wrapping on overflow preferred.  Will
other architectures (e.g. decimal) return?  It's unclear - Intel and IBM
are going to deliver decimal floating-point (see IEEE 754 2006), and
some of the same people favour restoring decimal integers next.  And,
yes, their long-term intent is for SOLELY decimal arithmetic!  Will
they make any headway?  Dunno.  MPI should follow Fortran in not
assuming whether they will succeed or fail.

But, even today, C's semantic model is incompatible with many other
important languages (e.g. Fortran, Cobol, Python and others), mainly due
to the overflow issue.  MPI really shouldn't adopt C's semantic model in
any interface that might force other languages to choose between their
own semantic model and C's, especially because MPI is being increasingly
considered as an interface in other languages.

Lastly, even C99 has not been generally accepted by the IT community,
especially outside the USA.  While <stdint.h> is one of the more widely
implemented aspects of it, I don't know anyone who has checked how
precisely the whole range of implementations adhere to the standard.
Also, there is a new C standard being worked on, and there was a
proposal to rewrite the specification of integer types and <stdint.h>,
incompatibly; that is certainly in abeyance, and may have been rejected
in toto, but I haven't checked the draft with a fine-tooth comb.

Regards,
Nick Maclaren.



--
Jeff Squyres
jsquyres at cisco.com<mailto:jsquyres at cisco.com>

<ATT00001..txt>

Marc Snir
4323 Siebel Center, 201 N Goodwin, IL 61801
Tel (217) 244 6568
Web http://www.cs.uiuc.edu/homes/snir