[Mpi-forum] "BigCount" rendering in PDF
Joseph Schuchart
schuchart at hlrs.de
Fri Aug 2 02:25:54 CDT 2019
> 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
> <mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at 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 at lists.mpi-forum.org
> <mailto:mpi-forum at 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 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 at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>
> >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>
> > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> >
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org <mailto:mpi-forum at lists.mpi-forum.org>
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
> --
> Jeff Hammond
> jeff.science at gmail.com <mailto:jeff.science at gmail.com>
> http://jeffhammond.github.io/
More information about the mpi-forum
mailing list