Re: [Mpi-forum] "BigCount" rendering in PDF

[Joseph Schuchart via mpi-forum]

> Are you saying that a C99 compiler won’t complaint if the user passes 
a 64b int to a 32b int argument? That’s a pretty stupid compiler if you 
ask me.


It is perfectly valid in C *and* C++ to pass a 64bit integer value as an 
argument to a 32bit integer parameter. The 64bit integer value will be 
converted to 32bit integer and thus potentially truncated. Depending on 
the original value this may result in a negative or positive 32bit 
signed integer value so depending on the size you want to send, MPI_Send 
may or may not detect the overflow.


Passing a pointer to a 64bit integer (int64_t*) for a parameter that is 
a pointer to a 32bit integer (int32_t*) is a bit different. In C, this 
is still valid and the compiler will only issue a warning about the type 
mismatch. C++ handles types stricter and pointers are not implicitly 
converted.



> I’m fine with putting MPI C11 in separate header that can #error if 
C11 isn’t supported.


I don't have a strong opinion on this and I don't know if this (and the 
implications of introducing a new header file) has been discussed in the 
forum already. Maybe Jeff S has considered this already?


> In any case, we can’t design MPI around ignorant users who don’t read 
about features they’re using.


I'm not advocating to change the design, i.e., I'm not arguing against 
having C11 _Generic selectors. I just think it would be beneficial to 
clearly mark the potential caveat.


Joseph


On 8/2/19 7:19 AM, Jeff Hammond wrote:
Are you saying that a C99 compiler won’t complaint if the user passes a 
64b int to a 32b int argument? That’s a pretty stupid compiler if you 
ask me.


I’m fine with putting MPI C11 in separate header that can #error if C11 
isn’t supported. That’s a pretty obvious user experience win that costs 
nothing. We are basically doing that for Fortran already.


Maclaren can just skip C11 and teach MPI in Fortran 2008 or C99 with the 
_x symbols if the C11 is too scary.


In any case, we can’t design MPI around ignorant users who don’t read 
about features they’re using. Doing so makes it impossible to do 
anything at all because there’s always somebody too ignorant to use some 
feature correctly, and the union of the ignorance covers all nontrivial 
changes.


Jeff

On Thu, Aug 1, 2019 at 7:28 AM Joseph Schuchart via mpi-forum 
mailto:mpi-forum@lists.mpi-forum.org>> 
wrote:


I think the point he wanted to make was that you won't see a
compile-time error if you /think/ you're using the MPI_Count overloads
but are in fact not, i.e., you are modernizing a legacy code base that
is stuck in the nineties and you introduce MPI_Count for size arguments
because the standard says you may do so now without a clear warning
that
this is only possible if you bump to C11. The compiler won't warn you,
the MPI standard may mention it in a subsection somewhere, which of
course you didn't read because you haven't had the time to read all ~1k
pages of 4.0, yet. Having a clear note attached to listings that these
overloads are constrained to C11 may help reduce the risk of
introducing
another caveat. MPI developers may be (more) familiar with the
differences between C99 and C11 but the average developer of HPC
software likely is not. And there are plenty of codes out there that
constrain themselves to ancient language versions, for reasons unknown
to me...

Joseph

On 8/1/19 12:56 PM, Jeff Hammond via mpi-forum wrote:
 > That’s why there will be C90/C99 compatible symbols as well. If
you don’t like C11, don’t use it. Nothing will happen. BigCount will
still work.
 >
 > C11 has been the default in GCC and Clang for a while. What
compilers are going to limit users to C99 for years to come?
 >
 > Jeff
 >
 >> On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum
mailto:mpi-forum@lists.mpi-forum.org>> wrote:
 >>
 >>> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote:
 >>>
 >>> B. C11 _Generic polymorphism kinda sucks, *and* we're in a
transition period where not all C compilers are C11-capable. Hence,
we're exposing up to *3* C bindings per MPI procedure to
applications (including explicitly exposing the "_x" variant where
relevant).
 >>
 >> This following point may have already been debated, so please
excuse me if
 >> has.  Let's skip the politics, for the sake of all our blood
pressures.
 >>
 >> The executive summary is that the failure mode pointed out by Joseph
 >> Schuchart is going to be a very, very serious problem for
BigCount users,
 >> and continue for the forseeable future.  I would guess until at
least
 >> 2025, and possibly long after that.
 >>
 >> Speaking as someone who may be teaching MPI programming again,
with an
 >> emphasis on reliability and portability, I would almost
certainly add
 >> warnings that would be, roughly: 

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Hammond via mpi-forum]

Are you saying that a C99 compiler won’t complaint if the user passes a 64b
int to a 32b int argument? That’s a pretty stupid compiler if you ask me.

I’m fine with putting MPI C11 in separate header that can #error if C11
isn’t supported. That’s a pretty obvious user experience win that costs
nothing. We are basically doing that for Fortran already.

Maclaren can just skip C11 and teach MPI in Fortran 2008 or C99 with the _x
symbols if the C11 is too scary.

In any case, we can’t design MPI around ignorant users who don’t read about
features they’re using. Doing so makes it impossible to do anything at all
because there’s always somebody too ignorant to use some feature correctly,
and the union of the ignorance covers all nontrivial changes.

Jeff

On Thu, Aug 1, 2019 at 7:28 AM Joseph Schuchart via mpi-forum <
mpi-forum@lists.mpi-forum.org> wrote:

> I think the point he wanted to make was that you won't see a
> compile-time error if you /think/ you're using the MPI_Count overloads
> but are in fact not, i.e., you are modernizing a legacy code base that
> is stuck in the nineties and you introduce MPI_Count for size arguments
> because the standard says you may do so now without a clear warning that
> this is only possible if you bump to C11. The compiler won't warn you,
> the MPI standard may mention it in a subsection somewhere, which of
> course you didn't read because you haven't had the time to read all ~1k
> pages of 4.0, yet. Having a clear note attached to listings that these
> overloads are constrained to C11 may help reduce the risk of introducing
> another caveat. MPI developers may be (more) familiar with the
> differences between C99 and C11 but the average developer of HPC
> software likely is not. And there are plenty of codes out there that
> constrain themselves to ancient language versions, for reasons unknown
> to me...
>
> Joseph
>
> On 8/1/19 12:56 PM, Jeff Hammond via mpi-forum wrote:
> > That’s why there will be C90/C99 compatible symbols as well. If you
> don’t like C11, don’t use it. Nothing will happen. BigCount will still work.
> >
> > C11 has been the default in GCC and Clang for a while. What compilers
> are going to limit users to C99 for years to come?
> >
> > Jeff
> >
> >> On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum <
> mpi-forum@lists.mpi-forum.org> wrote:
> >>
> >>> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote:
> >>>
> >>> B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition
> period where not all C compilers are C11-capable. Hence, we're exposing up
> to *3* C bindings per MPI procedure to applications (including explicitly
> exposing the "_x" variant where relevant).
> >>
> >> This following point may have already been debated, so please excuse me
> if
> >> has.  Let's skip the politics, for the sake of all our blood pressures.
> >>
> >> The executive summary is that the failure mode pointed out by Joseph
> >> Schuchart is going to be a very, very serious problem for BigCount
> users,
> >> and continue for the forseeable future.  I would guess until at least
> >> 2025, and possibly long after that.
> >>
> >> Speaking as someone who may be teaching MPI programming again, with an
> >> emphasis on reliability and portability, I would almost certainly add
> >> warnings that would be, roughly: "Don't touch BigCount if you can find a
> >> way round it; and be paranoid about it if you use it."  I already do
> that
> >> about I/O attributes, for similar reasons.  That isn't good.
> >>
> >> I don't know how you would document that, but the MPI standard already
> >> has gotchas that aren't easy to find, and adding another one isn't good,
> >> either.
> >>
> >> The explanation:
> >>
> >> C99 was not received favourably by most of the C-using community (I
> don't
> >> mean compilers here).  I tracked a dozen important, active projects, and
> >> it was 2010/11 (yes, over a decade) before even half of them converted
> >> from C90 to C99 as a base.  I last checked a few years ago, but quite a
> >> few C99 features were still not reliably available in compilers; I know
> >> that many of the ones I found still aren't.  Courses are another
> problem,
> >> because they rarely include warnings about gotchas caused by standards
> >> differences (and there are lots between C90 and C99).
> >>
> >> I haven't tracked C11 as carefully, but the evidence I have seen is
> that it
> >> received even less interest and acceptance than C99, so people are going
> >> to be using C99 compilers for a LONG time yet.  There is also the
> problem
> >> that C is not a language that is upwards compatible between versions,
> but
> >> C++ takes more notice, so C++ compilers' C support (which is arguably
> more
> >> important than direct C support, because people call MPI using C++'s C
> >> interface) is often in conflict.  This is almost certainly a case where
> >> that will be true, but it may not affect these interfaces - I can't say.
> >>
> >> The result is that C 

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Hammond via mpi-forum]

That’s why there will be C90/C99 compatible symbols as well. If you don’t like 
C11, don’t use it. Nothing will happen. BigCount will still work.

C11 has been the default in GCC and Clang for a while. What compilers are going 
to limit users to C99 for years to come?

Jeff

> On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum 
>  wrote:
> 
>> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote:
>> 
>> B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition period 
>> where not all C compilers are C11-capable. Hence, we're exposing up to *3* C 
>> bindings per MPI procedure to applications (including explicitly exposing 
>> the "_x" variant where relevant).
> 
> This following point may have already been debated, so please excuse me if
> has.  Let's skip the politics, for the sake of all our blood pressures.
> 
> The executive summary is that the failure mode pointed out by Joseph
> Schuchart is going to be a very, very serious problem for BigCount users,
> and continue for the forseeable future.  I would guess until at least
> 2025, and possibly long after that.
> 
> Speaking as someone who may be teaching MPI programming again, with an
> emphasis on reliability and portability, I would almost certainly add
> warnings that would be, roughly: "Don't touch BigCount if you can find a
> way round it; and be paranoid about it if you use it."  I already do that
> about I/O attributes, for similar reasons.  That isn't good.
> 
> I don't know how you would document that, but the MPI standard already
> has gotchas that aren't easy to find, and adding another one isn't good,
> either.
> 
> The explanation:
> 
> C99 was not received favourably by most of the C-using community (I don't
> mean compilers here).  I tracked a dozen important, active projects, and
> it was 2010/11 (yes, over a decade) before even half of them converted
> from C90 to C99 as a base.  I last checked a few years ago, but quite a
> few C99 features were still not reliably available in compilers; I know
> that many of the ones I found still aren't.  Courses are another problem,
> because they rarely include warnings about gotchas caused by standards
> differences (and there are lots between C90 and C99).
> 
> I haven't tracked C11 as carefully, but the evidence I have seen is that it
> received even less interest and acceptance than C99, so people are going
> to be using C99 compilers for a LONG time yet.  There is also the problem
> that C is not a language that is upwards compatible between versions, but
> C++ takes more notice, so C++ compilers' C support (which is arguably more
> important than direct C support, because people call MPI using C++'s C
> interface) is often in conflict.  This is almost certainly a case where
> that will be true, but it may not affect these interfaces - I can't say.
> 
> The result is that C code (and, worse, libraries) often require specific
> versions (i.e. not just 'any standard later than'). I agree that it looks
> likely that generic interfaces are going to be one of the more widely
> implemented parts of C99, but don't discount the problem of people using
> multiple libraries where other ones constrain the C version for other
> reasons.
> 
> ___
> mpi-forum mailing list
> mpi-forum@lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[N.M. Maclaren via mpi-forum]

On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote:


B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition 
period where not all C compilers are C11-capable. Hence, we're exposing 
up to *3* C bindings per MPI procedure to applications (including 
explicitly exposing the "_x" variant where relevant).


This following point may have already been debated, so please excuse me if
has.  Let's skip the politics, for the sake of all our blood pressures.

The executive summary is that the failure mode pointed out by Joseph
Schuchart is going to be a very, very serious problem for BigCount users,
and continue for the forseeable future.  I would guess until at least
2025, and possibly long after that.

Speaking as someone who may be teaching MPI programming again, with an
emphasis on reliability and portability, I would almost certainly add
warnings that would be, roughly: "Don't touch BigCount if you can find a
way round it; and be paranoid about it if you use it."  I already do that
about I/O attributes, for similar reasons.  That isn't good.

I don't know how you would document that, but the MPI standard already
has gotchas that aren't easy to find, and adding another one isn't good,
either.

The explanation:

C99 was not received favourably by most of the C-using community (I don't
mean compilers here).  I tracked a dozen important, active projects, and
it was 2010/11 (yes, over a decade) before even half of them converted
from C90 to C99 as a base.  I last checked a few years ago, but quite a
few C99 features were still not reliably available in compilers; I know
that many of the ones I found still aren't.  Courses are another problem,
because they rarely include warnings about gotchas caused by standards
differences (and there are lots between C90 and C99).

I haven't tracked C11 as carefully, but the evidence I have seen is that it
received even less interest and acceptance than C99, so people are going
to be using C99 compilers for a LONG time yet.  There is also the problem
that C is not a language that is upwards compatible between versions, but
C++ takes more notice, so C++ compilers' C support (which is arguably more
important than direct C support, because people call MPI using C++'s C
interface) is often in conflict.  This is almost certainly a case where
that will be true, but it may not affect these interfaces - I can't say.

The result is that C code (and, worse, libraries) often require specific
versions (i.e. not just 'any standard later than'). I agree that it looks
likely that generic interfaces are going to be one of the more widely
implemented parts of C99, but don't discount the problem of people using
multiple libraries where other ones constrain the C version for other
reasons.

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jed Brown via mpi-forum]

"Jeff Squyres \(jsquyres\) via mpi-forum"  
writes:

> On Jul 31, 2019, at 12:59 PM, Jeff Hammond  wrote:
>> 
>> “C++ compilers shall produce the same result as C11 generic.” Why does this 
>> need to say anything different for profiling and tools? Is this impossible?
>
> Is there a way to have C++ overloading call the same symbols that we'll 
> dispatch to from C11 _Generic?  (i.e., not-symbol-munged MPI_Send and 
> MPI_Send_x)

You have MPI_Send and MPI_Send_x declared extern "C", so why not:

#ifdef __cplusplus
static inline int MPI_Send(const void *buf, MPI_Count count,
  MPI_Datatype datatype, int dest, int tag, MPI_Comm comm)
{
  return MPI_Send_x(buf, count, datatype, dest, tag, comm);
}
#endif

When compiled with any optimization, this yields a direct call to
MPI_Send_x.  In any case, it doesn't add any mangled symbols to libmpi.

Note that you can't have an overload of the extern "C" symbol MPI_Send
taking "int count", but the extern "C" version works just fine for that.

  C++14 §7.5.5: If two declarations declare functions with the same name
  and parameter-type-list (8.3.5) to be members of the same namespace or
  declare objects with the same name to be members of the same namespace
  and the declarations give the names different language linkages, the
  program is ill-formed
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Squyres (jsquyres) via mpi-forum]

On Jul 31, 2019, at 12:59 PM, Jeff Hammond  wrote:
> 
> “C++ compilers shall produce the same result as C11 generic.” Why does this 
> need to say anything different for profiling and tools? Is this impossible?

Is there a way to have C++ overloading call the same symbols that we'll 
dispatch to from C11 _Generic?  (i.e., not-symbol-munged MPI_Send and 
MPI_Send_x)

If there's a way to do this, my objection will be greatly reduced (but still 
not zero).

-- 
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Joseph Schuchart via mpi-forum]

I agree with Jeff H that excluding C++ from the BigCount polymorphism 
seems unfortunate (and unintuitive for C++ developers). The _Generic 
selectors in C11 map a call to MPI_YYY() to either MPI_YYY(int) or 
MPI_YYY_x(MPI_Count). A C++ interface could do the same, with some macro 
work in the background, just using function overloading to select the 
right C99 call to make. There wouldn't be additional PMIPI calls to 
cover for tools and the amount of words required for C++ in the standard 
would be minimal.


Joseph

On 7/31/19 6:59 PM, Jeff Hammond via mpi-forum wrote:





On Jul 31, 2019, at 9:50 AM, Jeff Squyres (jsquyres)  wrote:


On Jul 31, 2019, at 12:14 PM, Jeff Hammond  wrote:


You're ignoring the long tail of consequences here -- what about PMPI/tools?  
What about other C++ features that we should be using, too?  ...?


No scope creep. No slippery slope. Do the one thing we need to go and stop. 
Leave the rest for MPI-5.


So PMPI/tools are out of scope?



“C++ compilers shall produce the same result as C11 generic.” Why does this 
need to say anything different for profiling and tools? Is this impossible?


Looking forward to your pull request.


I won’t lose any sleep if we don’t get both C11 and C++ overloads. I’m just 
saying it shouldn’t be hard to get C++ if we do C11.

Jeff
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum


___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Hammond via mpi-forum]

> On Jul 31, 2019, at 9:50 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> On Jul 31, 2019, at 12:14 PM, Jeff Hammond  wrote:
>> 
>>> You're ignoring the long tail of consequences here -- what about 
>>> PMPI/tools?  What about other C++ features that we should be using, too?  
>>> ...?
>> 
>> No scope creep. No slippery slope. Do the one thing we need to go and stop. 
>> Leave the rest for MPI-5. 
> 
> So PMPI/tools are out of scope?
> 

“C++ compilers shall produce the same result as C11 generic.” Why does this 
need to say anything different for profiling and tools? Is this impossible?

> Looking forward to your pull request.

I won’t lose any sleep if we don’t get both C11 and C++ overloads. I’m just 
saying it shouldn’t be hard to get C++ if we do C11.

Jeff
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Squyres (jsquyres) via mpi-forum]

On Jul 31, 2019, at 12:14 PM, Jeff Hammond  wrote:
> 
>> You're ignoring the long tail of consequences here -- what about PMPI/tools? 
>>  What about other C++ features that we should be using, too?  ...?
> 
> No scope creep. No slippery slope. Do the one thing we need to go and stop. 
> Leave the rest for MPI-5. 

So PMPI/tools are out of scope?

Looking forward to your pull request.

-- 
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Hammond via mpi-forum]

> 
>> If you don’t say C++, there’s no reason OMPI and MPICH can’t do the obvious, 
>> trivial and intelligent thing.
> 
> I guess I disagree with all three of those hyperbolic assertions.  :-)
> 
> You're ignoring the long tail of consequences here -- what about PMPI/tools?  
> What about other C++ features that we should be using, too?  ...?

No scope creep. No slippery slope. Do the one thing we need to go and stop. 
Leave the rest for MPI-5. 

Jeff
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Squyres (jsquyres) via mpi-forum]

On Jul 31, 2019, at 11:59 AM, Jeff Hammond  wrote:
> 
> It’s a long email to read on my phone while on vacation. 

Then stop reading on your phone while on vacation and defer this until next 
week!  ;-)

> If you don’t say C++, there’s no reason OMPI and MPICH can’t do the obvious, 
> trivial and intelligent thing.

I guess I disagree with all three of those hyperbolic assertions.  :-)

You're ignoring the long tail of consequences here -- what about PMPI/tools?  
What about other C++ features that we should be using, too?  ...?

-- 
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Hammond via mpi-forum]

It’s a long email to read on my phone while on vacation. 

You just need a sentence that says C++ compilers support C bindings, including 
the C11 generic stuff, just using a very different mechanism. Is that going to 
delay MPI-4?

In any case, all the issues with polymorphism is exactly why it’s so important 
to have explicit symbols for C89/C99 usage so that implementations can add 
extensions that do the polymorphism stuff if it doesn’t get voted in. If you 
don’t say C++, there’s no reason OMPI and MPICH can’t do the obvious, trivial 
and intelligent thing.

Jeff

Sent from my iPhone

> On Jul 31, 2019, at 8:03 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> On Jul 31, 2019, at 10:52 AM, Jeff Hammond  wrote:
>> 
>> You’re going to have to mention C++. You can’t just pretend that C++ 
>> supports C11 generic, because it explicitly doesn’t.
> 
> We are mentioning C++.  Please re-read my prior email.  
> 
>> And you really should do this because it’s ridiculous not to use C++ 
>> polymorphism if we use C11’s.
> 
> There are three options:
> 
> 1. Re-introduce C++ bindings, delay MPI-4.
> 2. Re-introduce C++ bindings, BigCount misses the MPI-4 train.
> 4. Do not re-introduce C++ bindings, BigCount catches the MPI-4 train.
> 
> The feedback from the Forum was that BigCount was a blocker/gating issue for 
> MPI-4.  Hence, this is why the BigCount WG is not planning at this time to 
> re-introduce C++ bindings via BigCount.
> 
> There is a longer term plan (think: MPI-5) to introduce a full-featured set 
> of C++ bindings to MPI -- one that does not necessarily have a 1:1 
> correspondence to the C bindings.  That is a different, much longer effort, 
> and will definitely not make it into MPI-4.
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> 
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[HOLMES Daniel via mpi-forum]

Hi Jeff,

To be clear, C++ currently calls/uses the C99 interface for MPI (unless it uses 
the no-long-standard but possibly-still-present-in-libraries C++ bindings). 
That will still be true after these BigCount changes: C++ will see only the C99 
symbols, just like any other non-C11-compliant compiler. Polymorphism will not 
be supported in C++ because it cannot use C11 _Generic (because that is part of 
the C11 standard and is *not* part of the C++ standard). It also cannot use C++ 
overloading because are choosing not to define any new C++ bindings in the 
MPI-4.0 standard. If libraries choose to supply C++ overloads, they may do so 
but they are not going to be part of the MPI-4.0 standard (they will have the 
same status as the Java bindings offered by Open MPI).

Cheers,
Dan.
—
Dr Daniel Holmes PhD
Architect (HPC Research)
d.hol...@epcc.ed.ac.uk
Phone: +44 (0) 131 651 3465
Mobile: +44 (0) 7940 524 088
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT
—
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336.
—

On 31 Jul 2019, at 16:03, Jeff Squyres (jsquyres) via mpi-forum 
mailto:mpi-forum@lists.mpi-forum.org>> wrote:

On Jul 31, 2019, at 10:52 AM, Jeff Hammond 
mailto:jeff.scie...@gmail.com>> wrote:

You’re going to have to mention C++. You can’t just pretend that C++ supports 
C11 generic, because it explicitly doesn’t.

We are mentioning C++.  Please re-read my prior email.

And you really should do this because it’s ridiculous not to use C++ 
polymorphism if we use C11’s.

There are three options:

1. Re-introduce C++ bindings, delay MPI-4.
2. Re-introduce C++ bindings, BigCount misses the MPI-4 train.
4. Do not re-introduce C++ bindings, BigCount catches the MPI-4 train.

The feedback from the Forum was that BigCount was a blocker/gating issue for 
MPI-4.  Hence, this is why the BigCount WG is not planning at this time to 
re-introduce C++ bindings via BigCount.

There is a longer term plan (think: MPI-5) to introduce a full-featured set of 
C++ bindings to MPI -- one that does not necessarily have a 1:1 correspondence 
to the C bindings.  That is a different, much longer effort, and will 
definitely not make it into MPI-4.

--
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Squyres (jsquyres) via mpi-forum]

On Jul 31, 2019, at 10:52 AM, Jeff Hammond  wrote:
> 
> You’re going to have to mention C++. You can’t just pretend that C++ supports 
> C11 generic, because it explicitly doesn’t.

We are mentioning C++.  Please re-read my prior email.  

> And you really should do this because it’s ridiculous not to use C++ 
> polymorphism if we use C11’s.

There are three options:

1. Re-introduce C++ bindings, delay MPI-4.
2. Re-introduce C++ bindings, BigCount misses the MPI-4 train.
4. Do not re-introduce C++ bindings, BigCount catches the MPI-4 train.

The feedback from the Forum was that BigCount was a blocker/gating issue for 
MPI-4.  Hence, this is why the BigCount WG is not planning at this time to 
re-introduce C++ bindings via BigCount.

There is a longer term plan (think: MPI-5) to introduce a full-featured set of 
C++ bindings to MPI -- one that does not necessarily have a 1:1 correspondence 
to the C bindings.  That is a different, much longer effort, and will 
definitely not make it into MPI-4.

-- 
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Hammond via mpi-forum]

You’re going to have to mention C++. You can’t just pretend that C++ supports 
C11 generic, because it explicitly doesn’t. And you really should do this 
because it’s ridiculous not to use C++ polymorphism if we use C11’s.

Jeff

> On Jul 31, 2019, at 6:14 AM, Jeff Squyres (jsquyres) via mpi-forum 
>  wrote:
> 
>> On Jul 31, 2019, at 4:31 AM, Joseph Schuchart via mpi-forum 
>>  wrote:
>> 
>> Should we mark in the interface the fact that the MPI_Count overloads are 
>> only available in C11? I'm thinking about something similar to 
>> cppreference's distinction between C/C++ standard versions, e.g.,
>> 
>> 
>> ```
>> int MPI_Send(const void *buf, MPI_Count count, MPI_Datatype datatype, int 
>> dest, int tag, MPI_Comm comm) [>C11|C++]
>> ```
> 
> These are exactly the kind of discussions that I'd like to have before the 
> September meeting: what is the best way to render the output to convey the 
> information in an aesthetic way?  I'm terrible at this kind of stuff.
> 
> -
> 
> That being said, I would not want to mark anything as "C++", because the MPI 
> spec does not explicitly support C++ at all.  The text that will support this 
> ticket will only have an Advice to Implementors for those implementations who 
> want to continue to have an  that supports both C and C++.  Per 
> feedback we got in the Virtual Meeting last week, the advice is to *not* use 
> C++ polymorphism, and, instead, treat C++ as a complier that does not support 
> C11 _Generic (i.e., the MPI_Count-enabled version of MPI_Foo() will simply 
> not be available -- see Froozle).
> 
> The rationale here is that if an implementation supports C++ polymorphism, 
> there are three options:
> 
> 1. The standard needs to make official statements about C++, which basically 
> re-introduces formal C++ support in the MPI spec (which is a Big Deal)
> 2. PMPI-enabled tools will need to support non-standard C++ polymorphism in 
> order to guarantee that they can intercept all MPI APIs when the application 
> is written in C++
> 3. PMPI-enabled tools do not support intercepting all MPI APIs when the 
> application is written in C++
> 
> None of those 3 options are attractive.
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> 
> ___
> mpi-forum mailing list
> mpi-forum@lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Squyres (jsquyres) via mpi-forum]

On Jul 31, 2019, at 4:31 AM, Joseph Schuchart via mpi-forum 
 wrote:

> Should we mark in the interface the fact that the MPI_Count overloads are 
> only available in C11? I'm thinking about something similar to cppreference's 
> distinction between C/C++ standard versions, e.g.,
> 
> 
> ```
> int MPI_Send(const void *buf, MPI_Count count, MPI_Datatype datatype, int 
> dest, int tag, MPI_Comm comm) [>C11|C++]
> ```

These are exactly the kind of discussions that I'd like to have before the 
September meeting: what is the best way to render the output to convey the 
information in an aesthetic way?  I'm terrible at this kind of stuff.

-

That being said, I would not want to mark anything as "C++", because the MPI 
spec does not explicitly support C++ at all.  The text that will support this 
ticket will only have an Advice to Implementors for those implementations who 
want to continue to have an  that supports both C and C++.  Per feedback 
we got in the Virtual Meeting last week, the advice is to *not* use C++ 
polymorphism, and, instead, treat C++ as a complier that does not support C11 
_Generic (i.e., the MPI_Count-enabled version of MPI_Foo() will simply not be 
available -- see Froozle).

The rationale here is that if an implementation supports C++ polymorphism, 
there are three options:

1. The standard needs to make official statements about C++, which basically 
re-introduces formal C++ support in the MPI spec (which is a Big Deal)
2. PMPI-enabled tools will need to support non-standard C++ polymorphism in 
order to guarantee that they can intercept all MPI APIs when the application is 
written in C++
3. PMPI-enabled tools do not support intercepting all MPI APIs when the 
application is written in C++

None of those 3 options are attractive.

-- 
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [Mpi-forum] "BigCount" rendering in PDF

[Joseph Schuchart via mpi-forum]

Jeff,

The first look at the definitions might indeed be a bit confusing, as it 
is strange to see overloaded C functions (even though C11 _Generic has 
been around for a while). It is also not clear when the second variant 
(using MPI_Count) is available, that is only if C11 _Generic is 
supported by my compiler. Even worse, a C99 compiler will happily cast 
an MPI_Count argument passed by value to int without complaint or 
warning by default. Should we mark in the interface the fact that the 
MPI_Count overloads are only available in C11? I'm thinking about 
something similar to cppreference's distinction between C/C++ standard 
versions, e.g.,



```
int MPI_Send(const void *buf, int count, MPI_Datatype datatype, int 
dest, int tag, MPI_Comm comm)


int MPI_Send(const void *buf, MPI_Count count, MPI_Datatype datatype, 
int dest, int tag, MPI_Comm comm) [>C11|C++]


int MPI_Send_x(const void *buf, MPI_Count count, MPI_Datatype datatype,
int dest, int tag, MPI_Comm comm)
```

That way it is immediately clear that there is a catch here and users 
have to be careful. OpenShmem, for example, has that distinction too 
(although more explicit using paragraphs for different language flavors).


Cheers,
Joseph

On 7/30/19 6:13 PM, Jeff Squyres (jsquyres) via mpi-forum wrote:

_*SHORT VERSION*_

See the attached two PDFs for how "BigCount" will be rendered in the 
MPI-4.0 PDF (pt2pt chapter and pt2pt/external interfaces in Annex A).


Comments / suggestions are welcome, but you may only make comments / 
suggestions if you have read all of the "MORE DETAIL" section, below.


_*MORE DETAIL*_

We have split the work of the "BigCount" WG into two parts:

1. Updating all the bindings throughout the entire MPI spec.  This is 
further sub-divided into two parts:

    1a. Updating the bindings in the chapters of the MPI spec.
    1b. Updating the bindings listing in Annex A.

2. Updating text in various chapters (e.g., Terms and 
Language Bindings) describing BigCount, language consequences, 
describing how the bindings appear in the rest of the doc, ...etc.


We've incorporated all the feedback from the BigCount Virtual Meeting 
last week, and I'd like to share samples of how #1a and #1b will look in 
the MPI 4.0 PDF.


Text for #2 will be read at the September meeting (stay tuned -- that 
text will be published according to the normal 2-week deadline, etc.).


Attached are 2 documents:

1. The point-to-point chapter rendered in the new style.  Look at the 
bindings for MPI_SEND and MPI_RECV, for example.


2. Annex A rendered in the new style (only some of the bindings have 
been updated so far -- such as pt2pt and external interfaces).


If you are confused when looking at these PDFs (e.g., why are there up 
to 3 C bindings?), and/or if you weren't at the Virtual Meeting / didn't 
watch the Webex after the fact, the feedback we received from the 
Virtual Meeting is summarized below.  It is a lot of wordswordswords and 
is somewhat difficult to follow -- I highly suggest reading the rules 
below while simultaneously examining the attached PDFs.  The summary 
below should make much more sense when looking at concrete examples.


-

The overall intent is:

A. In MPI-4.0, expose "BigCount" functionality through language 
polymorphism in the C bindings and the mpi_f08 module (we are /_not_/ 
updating mpif.h or the mpi module).


B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition 
period where not all C compilers are C11-capable.  Hence, we're exposing 
up to *3* C bindings per MPI procedure to applications (including 
explicitly exposing the "_x" variant where relevant).


C. Fortran polymorphism "just works" (skipping a longer explanation here 
-- ask Rolf/Puri if you're interested in the details), so there will 
only be up to *2* F08 bindings per MPI procedure.


-

For each binding in the main text of the document:

1. Show the "plain" MPI_Foo(...) C binding (e.g., as it appeared in MPI-3.1)

2. If the binding has count or displacement arguments:
    2a. Show a second MPI_Foo() C binding with count and displacement 
arguments as MPI_Count and MPI_Aint, respectively.
    2b. If MPI_Foo() DOES NOT HAVE a corresponding MPI_Foo_x() in 
MPI-3.1, show a third MPI_Foo_x(...) C binding with count/displacement 
as MPI_Count/MPI_Aint.


3. Show the "plain" MPI_Foo(...) F08 binding (e.g., as it appeared in 
MPI-3.1)


4. If the binding has count or displacement arguments:
    4a. Show a second MPI_Foo() F08 binding with count and displacement 
arguments as INTEGER(KIND=MPI_COUNT_KIND) and INTEGER(MPI_ADDRESS_KIND), 
respectively.


5. Show the "plain" F90 binding

-

References:

- Slides we presented at the BigCount Virtual Meeting: 
https://docs.google.com/presentation/d/10D_ws5NYAOI8m6KZKb31s9HxiSSmc_k5C620Cuy3brY/edit


- Webex Recording of the BigCount Virtual Meeting: 
https://www.mpi-forum.org/virtual_meetings/


- Froozle MPI, a no-op MPI implementation showing a bindings 
implementation of 

Re: [Mpi-forum] "BigCount" rendering in PDF

[Jeff Squyres (jsquyres) via mpi-forum]

In the text:

- We consciously put the "old" binding first (i.e., the int/INTEGER-enabled 
one), just for familiarity.

In Annex A:

- It's an alphabetical listing.

-

I don't have strong feelings about this.  If the popular opinion is to move the 
C/F08 Count-enabled bindings first in the text renderings, it's a trivial 
change to make (it entails changing just a few lines of Python).




> On Jul 30, 2019, at 3:37 PM, Bangalore, Purushotham  wrote:
> 
> Any reason why the function with MPI_Count appears first in the function 
> index while it appears second in the chapter?
> 
> Get Outlook for Android
> 
> From: mpi-forum  on behalf of Jeff 
> Squyres (jsquyres) via mpi-forum 
> Sent: Tuesday, July 30, 2019 11:13:09 AM
> To: MPI Forum list 
> Cc: Jeff Squyres (jsquyres) 
> Subject: [Mpi-forum] "BigCount" rendering in PDF
>  
> SHORT VERSION
> 
> See the attached two PDFs for how "BigCount" will be rendered in the MPI-4.0 
> PDF (pt2pt chapter and pt2pt/external interfaces in Annex A).
> 
> Comments / suggestions are welcome, but you may only make comments / 
> suggestions if you have read all of the "MORE DETAIL" section, below.
> 
> MORE DETAIL
> 
> We have split the work of the "BigCount" WG into two parts:
> 
> 1. Updating all the bindings throughout the entire MPI spec.  This is further 
> sub-divided into two parts:
>1a. Updating the bindings in the chapters of the MPI spec.
>1b. Updating the bindings listing in Annex A.
> 
> 2. Updating text in various chapters (e.g., Terms and Language 
> Bindings) describing BigCount, language consequences, describing how the 
> bindings appear in the rest of the doc, ...etc.
> 
> We've incorporated all the feedback from the BigCount Virtual Meeting last 
> week, and I'd like to share samples of how #1a and #1b will look in the MPI 
> 4.0 PDF.
> 
> Text for #2 will be read at the September meeting (stay tuned -- that text 
> will be published according to the normal 2-week deadline, etc.).
> 
> Attached are 2 documents:
> 
> 1. The point-to-point chapter rendered in the new style.  Look at the 
> bindings for MPI_SEND and MPI_RECV, for example.
> 
> 2. Annex A rendered in the new style (only some of the bindings have been 
> updated so far -- such as pt2pt and external interfaces).
> 
> If you are confused when looking at these PDFs (e.g., why are there up to 3 C 
> bindings?), and/or if you weren't at the Virtual Meeting / didn't watch the 
> Webex after the fact, the feedback we received from the Virtual Meeting is 
> summarized below.  It is a lot of wordswordswords and is somewhat difficult 
> to follow -- I highly suggest reading the rules below while simultaneously 
> examining the attached PDFs.  The summary below should make much more sense 
> when looking at concrete examples.
> 
> -
> 
> The overall intent is:
> 
> A. In MPI-4.0, expose "BigCount" functionality through language polymorphism 
> in the C bindings and the mpi_f08 module (we are not updating mpif.h or the 
> mpi module).
> 
> B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition period 
> where not all C compilers are C11-capable.  Hence, we're exposing up to *3* C 
> bindings per MPI procedure to applications (including explicitly exposing the 
> "_x" variant where relevant).
> 
> C. Fortran polymorphism "just works" (skipping a longer explanation here -- 
> ask Rolf/Puri if you're interested in the details), so there will only be up 
> to *2* F08 bindings per MPI procedure.
> 
> -
> 
> For each binding in the main text of the document:
> 
> 1. Show the "plain" MPI_Foo(...) C binding (e.g., as it appeared in MPI-3.1)
> 
> 2. If the binding has count or displacement arguments:
>2a. Show a second MPI_Foo() C binding with count and displacement 
> arguments as MPI_Count and MPI_Aint, respectively.
>2b. If MPI_Foo() DOES NOT HAVE a corresponding MPI_Foo_x() in MPI-3.1, 
> show a third MPI_Foo_x(...) C binding with count/displacement as 
> MPI_Count/MPI_Aint.
> 
> 3. Show the "plain" MPI_Foo(...) F08 binding (e.g., as it appeared in MPI-3.1)
> 
> 4. If the binding has count or displacement arguments:
>4a. Show a second MPI_Foo() F08 binding with count and displacement 
> arguments as INTEGER(KIND=MPI_COUNT_KIND) and INTEGER(MPI_ADDRESS_KIND), 
> respectively.
> 
> 5. Show the "plain" F90 binding
> 
> -
> 
> References:
> 
> - Slides we presented at the BigCount Virtual Meeting: 
> https://docs.google.com/presentation/d/10D_ws5NYAOI8m6KZKb31s9HxiSSmc_k5C620Cuy3brY/edit
> 
> - Webex Recording of the BigCount Virtual Meeting: 
> https://www.mpi-forum.org/virtual_meetings/
> 
> - Froozle MPI, a no-op MPI implementation showing a bindings implementation 
> of BigCount: https://github.com/jsquyres/froozle-mpi
> 
> If you have read all the way down to this point, comments and feedback are 
> welcome.  :-)
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> 


-- 
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum 

Re: [Mpi-forum] "BigCount" rendering in PDF

[Bangalore, Purushotham via mpi-forum]

Any reason why the function with MPI_Count appears first in the function index 
while it appears second in the chapter?

Get Outlook for Android


From: mpi-forum  on behalf of Jeff 
Squyres (jsquyres) via mpi-forum 
Sent: Tuesday, July 30, 2019 11:13:09 AM
To: MPI Forum list 
Cc: Jeff Squyres (jsquyres) 
Subject: [Mpi-forum] "BigCount" rendering in PDF

SHORT VERSION

See the attached two PDFs for how "BigCount" will be rendered in the MPI-4.0 
PDF (pt2pt chapter and pt2pt/external interfaces in Annex A).

Comments / suggestions are welcome, but you may only make comments / 
suggestions if you have read all of the "MORE DETAIL" section, below.

MORE DETAIL

We have split the work of the "BigCount" WG into two parts:

1. Updating all the bindings throughout the entire MPI spec.  This is further 
sub-divided into two parts:
   1a. Updating the bindings in the chapters of the MPI spec.
   1b. Updating the bindings listing in Annex A.

2. Updating text in various chapters (e.g., Terms and Language 
Bindings) describing BigCount, language consequences, describing how the 
bindings appear in the rest of the doc, ...etc.

We've incorporated all the feedback from the BigCount Virtual Meeting last 
week, and I'd like to share samples of how #1a and #1b will look in the MPI 4.0 
PDF.

Text for #2 will be read at the September meeting (stay tuned -- that text will 
be published according to the normal 2-week deadline, etc.).

Attached are 2 documents:

1. The point-to-point chapter rendered in the new style.  Look at the bindings 
for MPI_SEND and MPI_RECV, for example.

2. Annex A rendered in the new style (only some of the bindings have been 
updated so far -- such as pt2pt and external interfaces).

If you are confused when looking at these PDFs (e.g., why are there up to 3 C 
bindings?), and/or if you weren't at the Virtual Meeting / didn't watch the 
Webex after the fact, the feedback we received from the Virtual Meeting is 
summarized below.  It is a lot of wordswordswords and is somewhat difficult to 
follow -- I highly suggest reading the rules below while simultaneously 
examining the attached PDFs.  The summary below should make much more sense 
when looking at concrete examples.

-

The overall intent is:

A. In MPI-4.0, expose "BigCount" functionality through language polymorphism in 
the C bindings and the mpi_f08 module (we are not updating mpif.h or the mpi 
module).

B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition period 
where not all C compilers are C11-capable.  Hence, we're exposing up to *3* C 
bindings per MPI procedure to applications (including explicitly exposing the 
"_x" variant where relevant).

C. Fortran polymorphism "just works" (skipping a longer explanation here -- ask 
Rolf/Puri if you're interested in the details), so there will only be up to *2* 
F08 bindings per MPI procedure.

-

For each binding in the main text of the document:

1. Show the "plain" MPI_Foo(...) C binding (e.g., as it appeared in MPI-3.1)

2. If the binding has count or displacement arguments:
   2a. Show a second MPI_Foo() C binding with count and displacement arguments 
as MPI_Count and MPI_Aint, respectively.
   2b. If MPI_Foo() DOES NOT HAVE a corresponding MPI_Foo_x() in MPI-3.1, show 
a third MPI_Foo_x(...) C binding with count/displacement as MPI_Count/MPI_Aint.

3. Show the "plain" MPI_Foo(...) F08 binding (e.g., as it appeared in MPI-3.1)

4. If the binding has count or displacement arguments:
   4a. Show a second MPI_Foo() F08 binding with count and displacement 
arguments as INTEGER(KIND=MPI_COUNT_KIND) and INTEGER(MPI_ADDRESS_KIND), 
respectively.

5. Show the "plain" F90 binding

-

References:

- Slides we presented at the BigCount Virtual Meeting: 
https://docs.google.com/presentation/d/10D_ws5NYAOI8m6KZKb31s9HxiSSmc_k5C620Cuy3brY/edit

- Webex Recording of the BigCount Virtual Meeting: 
https://www.mpi-forum.org/virtual_meetings/

- Froozle MPI, a no-op MPI implementation showing a bindings implementation of 
BigCount: https://github.com/jsquyres/froozle-mpi

If you have read all the way down to this point, comments and feedback are 
welcome.  :-)

--
Jeff Squyres
jsquy...@cisco.com

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum