January 2010 - mpi-forum - mailman3.cels.anl.gov

Fwd: Reboot milliways
by Jeff Squyres 28 Jan '10

28 Jan '10

FYI (milliways = meetings.mpi-forum.org and lists.mpi-forum.org) Begin forwarded message: > From: "Kim, DongInn" <> > Date: January 28, 2010 3:41:52 PM EST > Subject: Reboot milliways > > Hi, > > We need to reboot milliways due to its maintenance on Jan 29th, 2010. > > Date: Friday, Jan 29th, 2010 > Time: > - 5:00am-5:30am Pacific US time > - 6:00am-6:30am Mountain US time > - 7:00am-7:30am Central US time > - 8:00am-8:30am Eastern US time > - 1:00pm-1:30pm GMT > > The following services would not be available during the reboot. > - web > - mysql/postgresql > - mail / archive > - mailman > - jabber > > Please let me know if you have any issues or question about the outage. > > Regards, > > -- > - DongInn > > -- Jeff Squyres jsquyres(a)cisco.com

1 0

Follow up from the Jan meeting of the Forum
by Graham, Richard L. 27 Jan '10

27 Jan '10

Attendance at this last meeting was lower than normal, so I am following up with an e-mail message to let people know the crux of several key discussions that took place. First, the goal is to have finished this round of meeting of the MPI Forum by the end of calendar year 2011, and to release a single standard document at the end of the process, with no other formal release of the standard between now and then. That will be MPI 3.0. With this in mind, we are leaning towards releasing draft versions of the standard, as new sections are voted in. These will have the nature that they we don't expect them to change (otherwise why would we vote them in), but could change before the standard is finalized. These will be snap shots of the document repository as it stands at the end of a given meeting, or a few days after that. The expectation is that as soon as the nonblocking collectives are integrated into the document, and we go through a vote on this integration, we will release the first draft standard. To bring focus on individual items being discussed, and to let people know in advance what our plans are, we will start to focus on individual areas in future meetings. There will be on the order of eight hours of meeting time, either/or working group and plenary session, devoted to these topics. The current plan is March 8-10, 2010: RMA and Tools (first draft of an agenda will come out in the next week or so) May 3-5, 2010: Hybrid Programming and Backward Compatibility June 14-16: Fault Tolerance (async process control and piggy backing) and Fortran Sept 16-18: Fault Tolerance (failure recovery) and TBD Oct 11-13: TBD Dec 6-8: TBD We will finish filling out these details over time. The expectation is that for most of these items (not all) a first draft of text will be available within two meetings (if the decision is to move forward), which will kick off the formal process of standardization. For all but the RMA working group, where the time in the March meeting will formally be working group time, the expectation is that these discussions will be accompanied with working prototype code. This does not mean that the forum will not consider new items, but the window for considering such items is rapidly closing. As usual, comments back are welcome, Rich

1 0

Re: [Mpi-forum] Fwd: MPI_Count
by Cownie, James H 27 Jan '10

27 Jan '10

This is really from Nick McLaren... > Subject: Re: [Mpi-forum] Fwd: MPI_Count > > 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. No, positively not! MPI_COUNT would be an integer appropriate for the addressing model of the implementation - that might be 32 bits, 64 bits, 48 bits, 12 decimal digits, or whatever other size of integer matches the maximum size of data structure that the implementation supports. In C, it would often or usually be ptrdiff_t. Regards, Nick. -- Jim James Cownie <james.h.cownie(a)intel.com> SSG/DPD/PAT Tel: +44 117 9071438 -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Snir, Marc Sent: Tuesday, January 26, 2010 3:38 PM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] Fwd: MPI_Count 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(a)cam.ac.uk<mailto:[email protected]>> Date: January 26, 2010 8:15:24 AM EST To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com<mailto:[email protected]>> Cc: "Darius Buntinas" <buntinas(a)mcs.anl.gov<mailto:[email protected]>>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)cisco.com<mailto:[email protected]> <ATT00001..txt> Marc Snir 4323 Siebel Center, 201 N Goodwin, IL 61801 Tel (217) 244 6568 Web http://www.cs.uiuc.edu/homes/snir _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 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.

1 0

Re: [Mpi-forum] MPI_Count
by Rajeev Thakur 26 Jan '10

26 Jan '10

Another option perhaps would be to use MPI_Aint. It is large enough by definition and is already used in cases such as the size of a window in Win_create and for the extent of a datatype. Rajeev

1 0

Re: [Mpi-forum] MPI_Count
by Hubert Ritzdorf 26 Jan '10

26 Jan '10

I can remember that we had Fortran users and C users who had problems 32-bit count arguments on NEC SX systems. The Fortran users used the extended width option of the Fortran compiler and the corresponding MPI library to overcome the problem. The C users used the same (extended width) version of MPI library and an extension in our MPI include file (there is a typedef for int's in the function interfaces). Hubert -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Rajeev Thakur Sent: Monday, January 25, 2010 12:52 AM To: 'Main MPI Forum mailing list' Subject: Re: [Mpi-forum] MPI_Count I don't know who wants to communicate >2GB at a time, but HP seemed to have enough users wanting it to cause Kannan to create and pursue ticket #117 until he moved to a different project. Rajeev > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of > Underwood, Keith D > Sent: Sunday, January 24, 2010 5:20 PM > To: Main MPI Forum mailing list; mpi3(a)lists.mpi-forum.org > Subject: Re: [Mpi-forum] MPI_Count > > > Still seems a little odd to have a solution for I/O > functions and not > > for communication functions (the original ticket was for > communication > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117) > > If > 2GB can be written from a single process in a single > call, they > > can also be communicated. If it is tedious to break up the > write into > > smaller writes, the same applies to communication. > > "can be" and "will be" are very different phrases. The > feeling within the group that was there Thursday morning was > that the "way 64 bit is done" (TM) is to replicate all of the > function calls. The group felt like a compelling case had > been made for I/O, because you would want to write all of > your memory to file (e.g. checkpointing) and memory per node > is growing beyond 2 GB. However, it was much harder to make > the case that you really wanted to send that much data from a > contiguous location to any other node. In fact, someone made > the statement "all of the application users understand that > you can't do that and still scale on any network in the > foreseeable future". > > Your interoperability comments may be a more motivating > example, but as of Thursday morning, it was clear that there > was not consensus among the forum members who were - > especially given the pain that is going to be involved in > fixing this for the general case. > > Keith > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] MPI_Count
by Hubert Ritzdorf 26 Jan '10

26 Jan '10

I can remember that we had Fortran users and C users who had problems 32-bit count arguments on NEC SX systems. The Fortran users used the extended width option of the Fortran compiler and the corresponding MPI library to overcome the problem. The C users used the same (extended width) version of MPI library and an extension in our MPI include file (there is a typedef for int's in the function interfaces). Hubert -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Rajeev Thakur Sent: Monday, January 25, 2010 12:52 AM To: 'Main MPI Forum mailing list' Subject: Re: [Mpi-forum] MPI_Count I don't know who wants to communicate >2GB at a time, but HP seemed to have enough users wanting it to cause Kannan to create and pursue ticket #117 until he moved to a different project. Rajeev > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of > Underwood, Keith D > Sent: Sunday, January 24, 2010 5:20 PM > To: Main MPI Forum mailing list; mpi3(a)lists.mpi-forum.org > Subject: Re: [Mpi-forum] MPI_Count > > > Still seems a little odd to have a solution for I/O > functions and not > > for communication functions (the original ticket was for > communication > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117) > > If > 2GB can be written from a single process in a single > call, they > > can also be communicated. If it is tedious to break up the > write into > > smaller writes, the same applies to communication. > > "can be" and "will be" are very different phrases. The > feeling within the group that was there Thursday morning was > that the "way 64 bit is done" (TM) is to replicate all of the > function calls. The group felt like a compelling case had > been made for I/O, because you would want to write all of > your memory to file (e.g. checkpointing) and memory per node > is growing beyond 2 GB. However, it was much harder to make > the case that you really wanted to send that much data from a > contiguous location to any other node. In fact, someone made > the statement "all of the application users understand that > you can't do that and still scale on any network in the > foreseeable future". > > Your interoperability comments may be a more motivating > example, but as of Thursday morning, it was clear that there > was not consensus among the forum members who were - > especially given the pain that is going to be involved in > fixing this for the general case. > > Keith > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Fwd: MPI_Count
by Snir, Marc 26 Jan '10

26 Jan '10

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(a)cam.ac.uk<mailto:[email protected]>> Date: January 26, 2010 8:15:24 AM EST To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com<mailto:[email protected]>> Cc: "Darius Buntinas" <buntinas(a)mcs.anl.gov<mailto:[email protected]>>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)cisco.com<mailto:[email protected]> <ATT00001..txt> Marc Snir 4323 Siebel Center, 201 N Goodwin, IL 61801 Tel (217) 244 6568 Web http://www.cs.uiuc.edu/homes/snir

1 0

Fwd: MPI_Count
by Jeff Squyres 26 Jan '10

26 Jan '10

Here's Nick's reply. Thanks Nick! Begin forwarded message: > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > Date: January 26, 2010 8:15:24 AM EST > To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > Cc: "Darius Buntinas" <buntinas(a)mcs.anl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)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(a)cisco.com

1 0

Re: [Mpi-forum] MPI_Count
by N.M. Maclaren 26 Jan '10

26 Jan '10

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.

1 0

Re: [Mpi-forum] MPI_Count
by Jeff Squyres 25 Jan '10

25 Jan '10

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) -- Jeff Squyres jsquyres(a)cisco.com

1 0