[Mpi-forum] Fwd: MPI_Count

[Jeff Squyres]

Here's Nick's reply.  Thanks Nick!

Begin forwarded message:

> From: "N.M. Maclaren" <nmm1 at cam.ac.uk>
> Date: January 26, 2010 8:15:24 AM EST
> To: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
> Cc: "Darius Buntinas" <buntinas at mcs.anl.gov>, "Main MPI Forum mailing list" <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20100126/e9ad47c3/attachment-0001.html>