<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Rolf (et al),
<div class=""><br class="">
</div>
<div class="">I wrote a lengthy comment on that issue to capture my current understanding of your “really wrong” assertion.</div>
<div class=""><br class="">
</div>
<div class="">Broadly, we agree - I just wanted to write down the reasoning and nuances of that outcome.<br class="">
<div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="Apple-interchange-newline">
Cheers,</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Dan.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
—<br class="">
Dr Daniel Holmes PhD<br class="">
Architect (HPC Research)<br class="">
<a href="mailto:d.holmes@epcc.ed.ac.uk" class="">d.holmes@epcc.ed.ac.uk</a><br class="">
Phone: +44 (0) 131 651 3465<br class="">
Mobile: +44 (0) 7940 524 088<br class="">
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
—</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
—</div>
</div>
</div>
</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 2 Nov 2019, at 09:13, Rolf Rabenseifner via mpiwg-large-counts <<a href="mailto:mpiwg-large-counts@lists.mpi-forum.org" class="">mpiwg-large-counts@lists.mpi-forum.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">After
the Telcon it seems that this ticket is really wrong.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Some
or all of the routines may/should be kept.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">And
it these routines arean essential part of the future large count concept.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Thank
you very much for pointing us to this ticket.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Rolf</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">-----
Jeff Hammond <</span><a href="mailto:jeff.science@gmail.com" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">jeff.science@gmail.com</a><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">>
wrote:</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
Rolf:<br class="">
<br class="">
Have you looked at<br class="">
<a href="https://github.com/mpiwg-large-count/large-count-issues/issues/6?" class="">https://github.com/mpiwg-large-count/large-count-issues/issues/6?</a><br class="">
<br class="">
Jeff<br class="">
<br class="">
On Fri, Nov 1, 2019 at 1:00 AM Rolf Rabenseifner <rabenseifner@hlrs.de><br class="">
wrote:<br class="">
<br class="">
<blockquote type="cite" class="">A small comment on the result of our telcon:<br class="">
- Postfix _l for int -> MPI_Count<br class="">
- Postfix _x for additionally<br class="">
MPI_Aint -> MPI_Count<br class="">
I.e., the additional routines in the derived datatype chapter.<br class="">
<br class="">
Two of them already exist<br class="">
MPI_Type_get_(true)extent_x<br class="">
<br class="">
In Fortran we will have then for the<br class="">
same routine two aliases:<br class="">
<br class="">
- the overload one without _x<br class="">
- and the explicit one with _x<br class="">
<br class="">
For both ones, the internal function name is the same, with _x.<br class="">
<br class="">
Best regards<br class="">
Rolf<br class="">
<br class="">
<br class="">
----- Jeff Hammond <jeff.science@gmail.com> wrote:<br class="">
<blockquote type="cite" class="">On Thu, Oct 31, 2019 at 7:48 AM Rolf Rabenseifner <rabenseifner@hlrs.de><br class="">
wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Dear all,<br class="">
<br class="">
here my summary as input for our telcon today.<br class="">
<br class="">
In principle, it is a very simple question:<br class="">
<br class="">
with large Counts, do we<br class="">
- keep all MPI_Aint<br class="">
- or do we substitute MPI_Aint by MPI_Count?<br class="">
<br class="">
</blockquote>
<br class="">
I haven't been involved as much lately but did we not use MPI_Count for<br class="">
count and element displacements in the large count proposal? We need to<br class="">
use MPI_Aint for offsets into memory because that is what this type is<br class="">
</blockquote>
for.<br class="">
<blockquote type="cite" class=""><br class="">
Jeff<br class="">
<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
In principle, the MPI Forum answered this question already<br class="">
for MPI-3.0 in 2012 with a clear YES:<br class="">
<br class="">
int MPI_Type_get_extent(MPI_Datatype datatype,<br class="">
MPI_Aint *lb, MPI_Aint *extent)<br class="">
int MPI_Type_get_extent_x(MPI_Datatype datatype,<br class="">
MPI_Count *lb, MPI_Count *extent)<br class="">
<br class="">
About Jeff H. question:<br class="">
If we limit the API to not support MPI_Count<br class="">
means that an MPI implementation has not really such quality options<br class="">
when using I/O fileviews, because the API is restricted to<br class="">
MPI_Aint (which should be implemented based on the, e.g.,<br class="">
64bit memory system).<br class="">
<br class="">
About Jim's comment:<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Apologies, it's been a while since I looked at the I/O interfaces.<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
If<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">I/O<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">only needs relative displacements that have normal integer<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
semantics,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">then<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">I don't see why MPI_Count would not work for this purpose. If you<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
have<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">an<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI_Aint that contains a relative displacement, it also has normal<br class="">
</blockquote>
</blockquote>
integer<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">semantics and can be converted to an MPI_Count.<br class="">
</blockquote>
</blockquote>
<br class="">
Yes, but this automatically implies that the datatypes must also<br class="">
be able to handle MPI_Count.<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">The only case we really<br class="">
need to look out for is when an integer type contains an absolute<br class="">
</blockquote>
</blockquote>
address.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">In those cases, the quantity in the variable cannot be treated as a<br class="">
</blockquote>
</blockquote>
normal<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">integer and we need special routines to work with it.<br class="">
</blockquote>
</blockquote>
<br class="">
Yes, this happens when we extend MPI_Aint in the derived datatype<br class="">
</blockquote>
</blockquote>
routines<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">to MPI_Count.<br class="">
<br class="">
But in principle, this is not a big Problem, as you all could see in<br class="">
the previous emails:<br class="">
<br class="">
- We must do for MPI_Count the same as we did for MPI_Aint,<br class="">
i.e., we'll have long versions of the routines<br class="">
MPI_Get_address, MPI_Aint_diff, MPI_Aint_add<br class="">
<br class="">
- And we must ensure that the type cast from MPI_Aint to<br class="">
MPI_Count works, which is a small new advice to implementors<br class="">
for MPI_Det_address.<br class="">
<br class="">
Therefore again my 4 questions:<br class="">
<br class="">
- Should the new large count routines be prepared for<br class="">
more than 10 or 20 Exabyte files where we need 64/65 or<br class="">
or 65/66 unsigned/signed integers for relative byte<br class="">
displacements or byte counts?<br class="">
If yes, then all MPI_Aint arguments must be substituted by MPI_Count.<br class="">
<br class="">
(In other words, do we want to be prepared for another 25 years of<br class="">
</blockquote>
</blockquote>
MPI?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">:-)<br class="">
<br class="">
As stated above, the MPI-Forum already decided 2012 with a YES.<br class="">
<br class="">
- Should we allow that these new routines are also used for memory<br class="">
description,<br class="">
where we typically need only the large MPI_Count "count" arguments?<br class="">
(or should we provide two different new routines for each routine<br class="">
</blockquote>
</blockquote>
that<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> currently has int Count/... and MPI_Aint disp/... arguments)<br class="">
<br class="">
I expect, that nobody wants to have two different large versions of<br class="">
for example MPI_Type_create_struct.<br class="">
<br class="">
- Should we allow a mix of old and new routines, especially for<br class="">
memory-based<br class="">
usage, that old-style MPI_Get_address is used to retrieve an absolute<br class="">
address and then, e.g., new style MPI_Type_create_struct with<br class="">
MPI_Count blocklength and displacements is used?<br class="">
<br class="">
I expect that forbidding such a mix would be a problem for Software<br class="">
development.<br class="">
Often old-style modules must work together with new-style modules.<br class="">
<br class="">
- Do we want to require for this type cast of MPI_Aint addr into<br class="">
</blockquote>
</blockquote>
MPI_Count<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> that it is allowed to do this cast with a normal assignment, rather<br class="">
than<br class="">
a special MPI function?<br class="">
<br class="">
I expect yes, because for must usage of MPI_Aint and MPI_Count,<br class="">
it is for relative displacements or byte counts, i.e. for normal<br class="">
integers and therefore automatic type cast between MPI_Aint<br class="">
and MPI_Count is a must.<br class="">
<br class="">
With yes to all four questions, the proposed solution above is<br class="">
the easiest way.<br class="">
<br class="">
Hope to see/hear you today in our telcon.<br class="">
<br class="">
Best regards<br class="">
Rolf<br class="">
<br class="">
<br class="">
----- Original Message -----<br class="">
<blockquote type="cite" class="">From: "Jeff Hammond" <jeff.science@gmail.com><br class="">
To: "mpiwg-large-counts" <mpiwg-large-counts@lists.mpi-forum.org><br class="">
Cc: "Rolf Rabenseifner" <rabenseifner@hlrs.de>, "Jim Dinan" <<br class="">
</blockquote>
james.dinan@gmail.com><br class="">
<blockquote type="cite" class="">Sent: Thursday, October 31, 2019 5:58:30 AM<br class="">
Subject: Re: [Mpiwg-large-counts] Large Count - the principles for<br class="">
</blockquote>
counts, sizes, and byte and nonbyte displacements<br class="">
<br class="">
<blockquote type="cite" class="">What if we just decided not to support IO displacements bigger than<br class="">
</blockquote>
</blockquote>
</blockquote>
2^63?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">What use case would that break? If the underlying filesystem uses<br class="">
</blockquote>
</blockquote>
</blockquote>
128b<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">displacements, fine, then MPI will promote into those before using<br class="">
</blockquote>
</blockquote>
</blockquote>
the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">system APIs.<br class="">
<br class="">
We already limit all sorts of things. For example, posting 17<br class="">
</blockquote>
</blockquote>
</blockquote>
billion<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Isends is not guaranteed to work. Maybe it does, but that's a<br class="">
</blockquote>
</blockquote>
</blockquote>
quality of<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">implementation issue. No sane person is going to have a data type<br class="">
</blockquote>
spanning<br class="">
<blockquote type="cite" class="">8 exabyte increments. Not now, not in 2030, not in 2040, not ever.<br class="">
<br class="">
Jeff<br class="">
<br class="">
On Wed, Oct 30, 2019 at 9:10 AM Jim Dinan via mpiwg-large-counts <<br class="">
mpiwg-large-counts@lists.mpi-forum.org> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Apologies, it's been a while since I looked at the I/O interfaces.<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
If<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">I/O<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">only needs relative displacements that have normal integer<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
semantics,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">then<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">I don't see why MPI_Count would not work for this purpose. If you<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
have<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">an<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI_Aint that contains a relative displacement, it also has normal<br class="">
</blockquote>
</blockquote>
integer<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">semantics and can be converted to an MPI_Count. The only case we<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
really<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">need to look out for is when an integer type contains an absolute<br class="">
</blockquote>
</blockquote>
address.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">In those cases, the quantity in the variable cannot be treated as a<br class="">
</blockquote>
</blockquote>
normal<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">integer and we need special routines to work with it. If MPI never<br class="">
</blockquote>
</blockquote>
treats<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">an MPI_Count quantity as an absolute address then MPI_Count should<br class="">
</blockquote>
</blockquote>
always<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">have normal integer semantics via the MPI interfaces and doesn't<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
need<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">special treatment. Unless, of course, we want to enable MPI_Count<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
that<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">large enough to need special support for basic operations, but<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
that's a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">different can of worms.<br class="">
<br class="">
~Jim.<br class="">
<br class="">
On Wed, Oct 30, 2019 at 11:02 AM Rolf Rabenseifner <<br class="">
</blockquote>
</blockquote>
rabenseifner@hlrs.de><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Dear Jim,<br class="">
<br class="">
<blockquote type="cite" class="">This sounds to me like it is creating again the same problem we<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
have<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">with<br class="">
<blockquote type="cite" class="">MPI_Aint --- one type doing too many things. If MPI_Aint can't<br class="">
</blockquote>
accommodate<br class="">
<blockquote type="cite" class="">absolute addresses in the I/O interfaces,<br class="">
</blockquote>
<br class="">
I/O has no absolute addresses. Only relative one, i.e., byte<br class="">
displacements<br class="">
and byte sizes.<br class="">
But they can be huge.<br class="">
<br class="">
The same routines are used for message passing, for example<br class="">
- MPI_TYPE_CREATE_STRUCT or<br class="">
- MPI_TYPE_CREATE_RESIZED<br class="">
<br class="">
<blockquote type="cite" class="">we should consider adding a new<br class="">
type like MPI_Faint (file address int) for this quantity and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
include<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">accessor routines to ensure manipulations of file addresses<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
respect<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">implementation defined meaning of the bits.<br class="">
</blockquote>
<br class="">
Yes, you are right, there are two possibilities:<br class="">
Substitute MPI_Aint in the large count version by<br class="">
- MPI_Count or<br class="">
- or by a new type MPI_Laint (for Long Aint)<br class="">
<br class="">
Others on this list have already expressed that they never want to<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
see<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">such a MPI_Laint<br class="">
<br class="">
<blockquote type="cite" class="">Even in C, it is not portable<br class="">
to do arithmetic on intptr_t because the integer representation<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
of an<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">address is implementation defined. We were careful in the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
definition of<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI_Aint_add and diff to describe them in terms of casting the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
absolute<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">address arguments back to pointers before performing arithmetic.<br class="">
</blockquote>
<br class="">
Yes, therefore, for this longer Version of MPI_Aint, let's name it<br class="">
for the Moment XXX, we Need<br class="">
MPI_XXX_diff and MPI_XXX_add,<br class="">
i.e. MPI_Laint_diff and _add or MPI_Count_diff and _add,<br class="">
which should be used only if the corresponding addresses<br class="">
are returned from MPI_Get_address_l.<br class="">
Or form MPI_Get_address, and with this we have again the<br class="">
type casting problem between MPI_Aint and MPI_Count or MPI_Laint.<br class="">
<br class="">
Best regards<br class="">
Rolf<br class="">
<br class="">
----- Original Message -----<br class="">
<blockquote type="cite" class="">From: "Jim Dinan" <james.dinan@gmail.com><br class="">
To: "Rolf Rabenseifner" <rabenseifner@hlrs.de><br class="">
Cc: "mpiwg-large-counts" <mpiwg-large-counts@lists.mpi-forum.org<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Sent: Wednesday, October 30, 2019 3:45:01 PM<br class="">
Subject: Re: [Mpiwg-large-counts] Large Count - the principles<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
for<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">counts, sizes, and byte and nonbyte displacements<br class="">
<br class="">
<blockquote type="cite" class="">This sounds to me like it is creating again the same problem we<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
have<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">with<br class="">
<blockquote type="cite" class="">MPI_Aint --- one type doing too many things. If MPI_Aint can't<br class="">
</blockquote>
accommodate<br class="">
<blockquote type="cite" class="">absolute addresses in the I/O interfaces, we should consider<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
adding a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">new<br class="">
<blockquote type="cite" class="">type like MPI_Faint (file address int) for this quantity and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
include<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">accessor routines to ensure manipulations of file addresses<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
respect<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">implementation defined meaning of the bits. Even in C, it is not<br class="">
</blockquote>
portable<br class="">
<blockquote type="cite" class="">to do arithmetic on intptr_t because the integer representation<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
of an<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">address is implementation defined. We were careful in the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
definition of<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI_Aint_add and diff to describe them in terms of casting the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
absolute<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">address arguments back to pointers before performing arithmetic.<br class="">
<br class="">
~Jim.<br class="">
<br class="">
On Wed, Oct 30, 2019 at 5:18 AM Rolf Rabenseifner <<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Dear all and Jim,<br class="">
<br class="">
Jim asked:<br class="">
<blockquote type="cite" class="">When you assign an MPI_Aint to an MPI_Count, there are two<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
cases<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">depending<br class="">
<blockquote type="cite" class="">on what the bits in the MPI_Aint represent: absolute address<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
and<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">relative<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">displacements. The case where you assign an address to a<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
count<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">doesn't<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">make sense to me. Why would one do this and why should MPI<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
support<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">it?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">The case where you assign a displacement to a count seems<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
fine,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">you<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">would<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">want sign extension to happen.<br class="">
</blockquote>
<br class="">
The answer is very simple:<br class="">
All derived datatype routines serve describing of memory **and**<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
file<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">space.<br class="">
<br class="">
Therefore, the large count working group should decide:<br class="">
- Should the new large count routines be prepared for more than<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
10<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">or<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">20<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Exabyte<br class="">
files where we need 64/65 or 65/66 unsigned/signed integers<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
for<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">relative<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">byte<br class="">
displacements or byte counts?<br class="">
If yes, then all MPI_Aint arguments must be substituted by<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Count.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> (In other words, do we want to be prepared for another 25<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
years of<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">:-)<br class="">
- Should we allow that these new routines are also used for<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
memory<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">description,<br class="">
where we typically need only the large MPI_Count "count"<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
arguments?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> (or should we provide two different new routines for each<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
routine<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">that<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> currently has int Count/... and MPI_Aint disp/... arguments)<br class="">
- Should we allow a mix of old and new routines, especially for<br class="">
memory-based<br class="">
usage, that old-style MPI_Get_address is used to retrieve an<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
absolute<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> address and then, e.g., new style MPI_Type_create_struct with<br class="">
MPI_Count blocklength and displacements is used?<br class="">
- Do we want to require for this type cast of MPI_Aint addr into<br class="">
</blockquote>
</blockquote>
MPI_Count<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> that it is allowed to do this cast with a normal assignment,<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
rather<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">than<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
a special MPI function?<br class="">
<br class="">
If we answer all four questions with yes (and in my opinion, we<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
must)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">then Jim's question<br class="">
"Why would one do this [assign an address to a Count]<br class="">
and why should MPI support it?"<br class="">
is answered with this set of reasons.<br class="">
<br class="">
I would say, that this is the most complex decision that the<br class="">
large count working group has to decide.<br class="">
A wrong decision would be hard to be fixed in the future.<br class="">
<br class="">
Best regards<br class="">
Rolf<br class="">
<br class="">
----- Original Message -----<br class="">
<blockquote type="cite" class="">From: "Jim Dinan" <james.dinan@gmail.com><br class="">
To: "Rolf Rabenseifner" <rabenseifner@hlrs.de><br class="">
Cc: "mpiwg-large-counts" <<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mpiwg-large-counts@lists.mpi-forum.org><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Sent: Tuesday, October 29, 2019 10:28:46 PM<br class="">
Subject: Re: [Mpiwg-large-counts] Large Count - the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
principles for<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">counts, sizes, and byte and nonbyte displacements<br class="">
<br class="">
<blockquote type="cite" class="">If you do pointer arithmetic, the compiler will ensure that<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">result is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">correct. If you convert a pointer into an integer and then<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
do the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">arithmetic, the compiler can't help you and the result is not<br class="">
</blockquote>
</blockquote>
</blockquote>
portable.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">This is why MPI_Aint_add describes what it does in terms of<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
pointer<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">arithmetic. The confusing and frustrating thing about<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Aint is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">that<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">it's one type for two very different purposes. Allowing<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
direct<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">+/-<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">on<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI_Aint values that represent addresses is not portable and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
is a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mistake<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">that we tried to correct with MPI_Aint_add/diff (I am happy to<br class="">
</blockquote>
</blockquote>
</blockquote>
strengthen<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">should to must if needed). It's perfectly fine to do<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
arithmetic<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">on<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI_Aint values that are displacements.<br class="">
<br class="">
When you assign an MPI_Aint to an MPI_Count, there are two<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
cases<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">depending<br class="">
<blockquote type="cite" class="">on what the bits in the MPI_Aint represent: absolute address<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
and<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">relative<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">displacements. The case where you assign an address to a<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
count<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">doesn't<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">make sense to me. Why would one do this and why should MPI<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
support<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">it?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">The case where you assign a displacement to a count seems<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
fine,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">you<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">would<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">want sign extension to happen.<br class="">
<br class="">
~Jim.<br class="">
<br class="">
On Tue, Oct 29, 2019 at 4:52 PM Rolf Rabenseifner <<br class="">
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Dear Jim,<br class="">
<br class="">
<blockquote type="cite" class="">(a3) Section 4.1.5 of MPI 3.1 states "To ensure<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
portability,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">arithmetic<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">on<br class="">
<blockquote type="cite" class="">absolute addresses should not be performed with the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
intrinsic<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">operators<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">\-"<br class="">
<blockquote type="cite" class="">and \+".<br class="">
</blockquote>
<br class="">
The major problem is, that we decided "should" and not<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
"maust" or<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">"shall",<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">because there is such many existing MPI-1 ... MPI-3.0 code<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
that<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">must<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">have<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">used + or - operators.<br class="">
<br class="">
The only objective, that is true from the beginning, that MPI<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
addresses<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">must be<br class="">
retrieved with MPI_Get_address.<br class="">
<br class="">
And the second also Major Problem is the new assigment of an<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Aint<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">value<br class="">
into an MPI_Count variable with MPI_Count larger than<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Aint.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
Therefore, I would prefere, that we keep this "should" and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
design in<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">long<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">term<br class="">
MPI_Get_address in a way that in principle MPI_Aint_diff and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
_add<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">need not to do anythin else as the + or - operator.<br class="">
<br class="">
And this depends on the meaning of the unsigned addresses,<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
i.e.,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">what is the sequence of addresses (i.e., is it really going<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
from<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">0 to FFFF...FFFF) and than mapping these addreses to the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mathematical<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">sequence<br class="">
of MPI_Aint which starts at -2**(n-1) and ends at 2**(n-1)-1.<br class="">
<br class="">
Thats all. For the moment, as far as the web and some emails<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
told<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">us,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">we are fare away from this contiguous 64-bit address space<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
(0 to<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">FFFF...FFFF).<br class="">
<br class="">
But we should be correctly prepared.<br class="">
<br class="">
Or in other words:<br class="">
<blockquote type="cite" class="">(a2) Should be solved by MPI_Aint_add/diff.<br class="">
</blockquote>
In my opinion no, it must be solved by MPI_Get_addr<br class="">
and MPI_Aint_add/diff can stay normal + or - operators.<br class="">
<br class="">
I should also mention, that of course all MPI routines that<br class="">
accept MPI_BOOTOM must reverse the work of MPI_Get_address<br class="">
to get back the real "unsigned" virtual addresses of the OS.<br class="">
<br class="">
The same what we already had if an implementation has chosen<br class="">
to use the address of an MPI common block as base for<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_BOTTOM.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Here, the MPI lib had the freedom to revert the mapping<br class="">
within MPI_Get_addr or within all functions called with<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_BOTTOM.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
Best regards<br class="">
Rolf<br class="">
<br class="">
<br class="">
<br class="">
----- Original Message -----<br class="">
<blockquote type="cite" class="">From: "Jim Dinan" <james.dinan@gmail.com><br class="">
To: "Rolf Rabenseifner" <rabenseifner@hlrs.de><br class="">
Cc: "mpiwg-large-counts" <<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mpiwg-large-counts@lists.mpi-forum.org><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Sent: Tuesday, October 29, 2019 3:58:18 PM<br class="">
Subject: Re: [Mpiwg-large-counts] Large Count - the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
principles<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">for<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">counts, sizes, and byte and nonbyte displacements<br class="">
<br class="">
<blockquote type="cite" class="">Hi Rolf,<br class="">
<br class="">
(a1) seems to me like another artifact of storing an<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
unsigned<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">quantity<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">in a<br class="">
<blockquote type="cite" class="">signed variable, i.e., the quantity in an MPI_Aint can be<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
an<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">unsigned<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">address or a signed displacement. Since we don't have an<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
unsigned<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">type<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">for<br class="">
<blockquote type="cite" class="">addresses, the user can't portably fix this above MPI. We<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
will<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">need<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">to<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">add<br class="">
<blockquote type="cite" class="">functions to deal with combinations of MPI_Aint and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Counts.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">This<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">essentially why we needed MPI_Aint_add/diff. Or ... the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
golden<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">(Au is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">gold) int ... MPI_Auint.<br class="">
<br class="">
(a2) Should be solved by MPI_Aint_add/diff.<br class="">
<br class="">
(a3) Section 4.1.5 of MPI 3.1 states "To ensure<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
portability,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">arithmetic<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">on<br class="">
<blockquote type="cite" class="">absolute addresses should not be performed with the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
intrinsic<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">operators<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">\-"<br class="">
<blockquote type="cite" class="">and \+". MPI_Aint_add was written carefully to indicate<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
that<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">"base"<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">argument is treated as an unsigned address and the "disp"<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
argument is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">treated as a signed displacement.<br class="">
<br class="">
~Jim.<br class="">
<br class="">
On Tue, Oct 29, 2019 at 5:19 AM Rolf Rabenseifner <<br class="">
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Dear Jim and all,<br class="">
<br class="">
I'm not sure whether I'm really able to understand your<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
email.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
I take the MPI view:<br class="">
<br class="">
(1) An absolute address can stored in an MPI_Aint variable<br class="">
with and only with MPI_Get_address or MPI_Aint_add.<br class="">
<br class="">
(2) A positive or negative number of bytes or a relative<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
address<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> which is by definition the amount of bytes between two<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
locations<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> in a MPI "sequential storage" (MPI-3.1 page 115)<br class="">
can be assigned with any method to an MPI_Aint<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
variable<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> as long as the original value fits into MPI_Aint.<br class="">
In both languages automatic type cast (i.e., sign<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
expansion)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> is done.<br class="">
<br class="">
(3) If users misuse MPI_Aint for storing anything else<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
into<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">MPI_Aint<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> variable then this is out of scope of MPI.<br class="">
If such values are used in a minus operation then it<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> out of the scope of MPI whether this makes sense.<br class="">
If the user is sure that the new value falls into<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
category<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">(2)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> then all is fine as long as the user is correct.<br class="">
<br class="">
I expect that your => is not a "greater or equal than".<br class="">
I expect that you noticed assignments.<br class="">
<br class="">
<blockquote type="cite" class="">intptr_t => MPI_Aint<br class="">
</blockquote>
"intptr_t: integer type capable of holding a pointer."<br class="">
<br class="">
<blockquote type="cite" class="">uintptr_t => ??? (Anyone remember the MPI_Auint "golden<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
Aint"<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">proposal?)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">"uintptr_t: unsigned integer type capable of holding a<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
pointer."<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
may fall exactly exactly into (3) when used for pointers.<br class="">
<br class="">
<br class="">
Especially on a 64 bit system the user may have in the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
future<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">exactly<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the problems (a), (a1), (a2) and (b) as described below.<br class="">
But here, the user is responsible, to for example<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
implement<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">(a3),<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">whereas for MPI_Get_address, the implementors of the MPI<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
library<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">are responsible and the MPI Forum may be responsible for<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
giving<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the correct advices.<br class="">
<br class="">
By the way, the golden MPI_Auint was never golden.<br class="">
Such need was "resolved" by introducing MPI_Aint_diff and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Aint_add<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">in MPI-3.1.<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">ptrdiff_t => MPI_Aint<br class="">
</blockquote>
"std::ptrdiff_t is the signed integer type of the result<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
of<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">subtracting<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">two pointers."<br class="">
<br class="">
may perfectly fit to (2).<br class="">
<br class="">
All of the following falls into category (2):<br class="">
<br class="">
<blockquote type="cite" class="">size_t (sizeof) => MPI_Count, int<br class="">
</blockquote>
"sizeof( type ) (1)<br class="">
sizeof expression (2)<br class="">
Both versions are constant expressions of type<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
std::size_t."<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">size_t (offsetof) => MPI_Aint, int<br class="">
</blockquote>
"Defined in header <cstddef><br class="">
#define offsetof(type, member) /*implementation-defined*/<br class="">
The macro offsetof expands to an integral constant<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
expression<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">of type std::size_t, the value of which is the offset, in<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
bytes,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">from the beginning of an object of specified type to ist<br class="">
specified member, including padding if any."<br class="">
<br class="">
Note that this offsetof has nothing to do with MPI_Offset.<br class="">
<br class="">
On a system with less than 2*31 byte and 4-byte int, it is<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
guaranteed<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">that size_t => int works.<br class="">
<br class="">
On a system with less than 2*63 byte and 8-byte MPI_Aint,<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
it<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">guaranteed<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">that size_t => MPI_Aint works.<br class="">
<br class="">
Problem: size_t is unsigned, int and MPI_Aint are signed.<br class="">
<br class="">
MPI_Count should be defined in a way that on systems with<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
more<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">than<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">2**63 Bytes of disc space, that MPI_Count can hold such<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
values,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">because<br class="">
int .LE. {MPI_Aint, MPI_Offset} .LE. MPI_Count<br class="">
<br class="">
Therefore size_t => MPI_Count should always work.<br class="">
<br class="">
<blockquote type="cite" class="">ssize_t => Mostly for error handling. Out of scope for<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">"In short, ssize_t is the same as size_t, but is a signed<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
type -<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">read ssize_t as “signed size_t”. ssize_t is able to<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
represent<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the number -1, which is returned by several system calls<br class="">
and library functions as a way to indicate error.<br class="">
For example, the read and write system calls: ...<br class="">
ssize_t read(int fildes, void *buf, size_t nbyte); ..."<br class="">
<br class="">
ssize_t fits therefore better to MPI_Aint, because both<br class="">
are signed types that can hold byte counts, but<br class="">
the value -1 in a MPI_Aint variable stands for a<br class="">
byte displacement of -1 bytes and not for an error code<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
-1.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<br class="">
All use of (2) is in principle no problem.<br class="">
------------------------------------------<br class="">
<br class="">
All the complex discussiuon of the last days is about (1):<br class="">
<br class="">
(1) An absolute address can stored in an MPI_Aint variable<br class="">
with and only with MPI_Get_address or MPI_Aint_add.<br class="">
<br class="">
In MPI-1 to MPI-3.0 and still in MPI-3.1 (here as may be<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
not<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">portable),<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">we also allow<br class="">
MPI_Aint variable := absolute address in MPI_Aint<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
variable<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> + or -<br class="">
a number of bytes (in any integer<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
type).<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
The result is then still in category (1).<br class="">
<br class="">
<br class="">
For the difference of two absolute addresses,<br class="">
MPI_Aint_diff can be used. The result is than MPI_Aint of<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
category<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">(2)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
In MPI-1 to MPI-3.0 and still in MPI-3.1 (here as may be<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
not<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">portable),<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">we also allow<br class="">
MPI_Aint variable := absolute address in MPI_Aint<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
variable<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> - absolute address in MPI_Aint<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
variable.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
The result is then in category (2).<br class="">
<br class="">
<br class="">
The problems we discuss the last days are about systems<br class="">
that internally use unsigned addresses and the MPI library<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
stores<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">these addresses into MPI_Aint variables and<br class="">
<br class="">
(a) a sequential storage can have virtual addresses that<br class="">
are both in the area with highest bit =0 and other<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
addresses<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> in the same sequential storage (i.e., same array or<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
structure)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> with highest bit =1.<br class="">
<br class="">
or<br class="">
(b) some higher bits contain segment addresses.<br class="">
<br class="">
(b) is not a problem as long as a sequential storage<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
resides<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> always within one Segment.<br class="">
<br class="">
Therefore, we only have to discuss (a).<br class="">
<br class="">
The two problems that we have is<br class="">
(a1) that for the minus operations an integer overflow<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
will<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> happen and must be ignored.<br class="">
(a2) if such addresses are expanded to larger variables,<br class="">
e.g., MPI_Count with more bits in MPI_Count than in<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Aint,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""> sign expansion will result in completely wring<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
results.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
And here, the most simple trick is,<br class="">
(a3) that MPI_Get_address really shall<br class="">
map the contiguous unsigned range from 0 to 2**64-1 to the<br class="">
signed (and also contiguous) range from -2**63 to 2**63-1<br class="">
by simple subtracting 2**63.<br class="">
With this simple trick in MPI_Get_address, Problems<br class="">
8a1) and (a2) are resolved.<br class="">
<br class="">
It looks like that (a) and therefore (a1) and (a2)<br class="">
may be far in the future.<br class="">
But they may be less far in the future, if a system may<br class="">
map the whole applications cluster address space<br class="">
into virtual memory (not cache coherent, but accessible).<br class="">
<br class="">
<br class="">
And all this is never or only partial written into the<br class="">
MPI Standard, also all is (well) known by the MPI Forum,<br class="">
with the following exceptions:<br class="">
- (a2) is new.<br class="">
- (a1) is solved in MPI-3.1 only for MPI_Aint_diff and<br class="">
MPI_Aint_add, but not for the operators - and +<br class="">
if a user will switch on integer overflow detection<br class="">
in the future when we will have such large systems.<br class="">
- (a3) is new and in principle solves the problem also<br class="">
for + and - operators.<br class="">
<br class="">
At lease (a1)+(a2) should be added as rationale to MPI-4.0<br class="">
and (a3) as advice to implementors within the framework<br class="">
of big count, because (a2) is newly coming with big count.<br class="">
<br class="">
I hope this helps a bit if you took the time to read<br class="">
this long email.<br class="">
<br class="">
Best regards<br class="">
Rolf<br class="">
<br class="">
<br class="">
<br class="">
----- Original Message -----<br class="">
<blockquote type="cite" class="">From: "mpiwg-large-counts" <<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mpiwg-large-counts@lists.mpi-forum.org<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">To: "mpiwg-large-counts" <<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mpiwg-large-counts@lists.mpi-forum.org><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Cc: "Jim Dinan" <james.dinan@gmail.com>, "James Dinan"<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">james.dinan@intel.com><br class="">
<blockquote type="cite" class="">Sent: Monday, October 28, 2019 5:07:37 PM<br class="">
Subject: Re: [Mpiwg-large-counts] Large Count - the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
principles<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">for<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">counts, sizes, and byte and nonbyte displacements<br class="">
<br class="">
<blockquote type="cite" class="">Still not sure I see the issue. MPI's memory-related<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
integers<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">should<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">map<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">to<br class="">
<blockquote type="cite" class="">types that serve the same function in C. If the base<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
language<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">broken<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">for<br class="">
<blockquote type="cite" class="">segmented addressing, we won't be able to fix it in a<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
library.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Looking<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">at the<br class="">
<blockquote type="cite" class="">mapping below, I don't see where we would have broken<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
it:<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
intptr_t => MPI_Aint<br class="">
uintptr_t => ??? (Anyone remember the MPI_Auint "golden<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
Aint"<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">proposal?)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">ptrdiff_t => MPI_Aint<br class="">
size_t (sizeof) => MPI_Count, int<br class="">
size_t (offsetof) => MPI_Aint, int<br class="">
ssize_t => Mostly for error handling. Out of scope for<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI?<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
It sounds like there are some places where we used<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
MPI_Aint<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">in<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">place<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">of<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">size_t<br class="">
<blockquote type="cite" class="">for sizes. Not great, but MPI_Aint already needs to be<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
at<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">least as<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">large<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">as<br class="">
<blockquote type="cite" class="">size_t, so this seems benign.<br class="">
<br class="">
~Jim.<br class="">
<br class="">
On Fri, Oct 25, 2019 at 8:25 PM Dinan, James via<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mpiwg-large-counts <<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">[<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mailto:mpiwg-large-counts@lists.mpi-forum.org |<br class="">
mpiwg-large-counts@lists.mpi-forum.org ] > wrote:<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
Jeff, thanks so much for opening up these old wounds.<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
I’m<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">not<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">sure<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">I<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">have enough<br class="">
<blockquote type="cite" class="">context to contribute to the discussion. Where can I<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
read up<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">on the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">issue with<br class="">
<blockquote type="cite" class="">MPI_Aint?<br class="">
<br class="">
<br class="">
<br class="">
I’m glad to hear that C signed integers will finally<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
have a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">well-defined<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">representation.<br class="">
<br class="">
<br class="">
<br class="">
~Jim.<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
From: Jeff Hammond < [ mailto:jeff.science@gmail.com |<br class="">
</blockquote>
jeff.science@gmail.com ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
Date: Thursday, October 24, 2019 at 7:03 PM<br class="">
To: "Jeff Squyres (jsquyres)" < [ mailto:<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
jsquyres@cisco.com<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">|<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">jsquyres@cisco.com<br class="">
<blockquote type="cite" class="">] ><br class="">
Cc: MPI BigCount Working Group < [ mailto:<br class="">
</blockquote>
mpiwg-large-counts@lists.mpi-forum.org<br class="">
<blockquote type="cite" class="">| mpiwg-large-counts@lists.mpi-forum.org ] >, "Dinan,<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
James"<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">< [<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mailto:james.dinan@intel.com | james.dinan@intel.com ]<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Subject: Re: [Mpiwg-large-counts] Large Count - the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
principles<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">for<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">counts,<br class="">
<blockquote type="cite" class="">sizes, and byte and nonbyte displacements<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
Jim (cc) suffered the most in MPI 3.0 days because of<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
AINT_DIFF and<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">AINT_SUM, so<br class="">
<blockquote type="cite" class="">maybe he wants to create this ticket.<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
Jeff<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
On Thu, Oct 24, 2019 at 2:41 PM Jeff Squyres (jsquyres)<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
< [<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mailto:jsquyres@cisco.com | jsquyres@cisco.com ] ><br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
wrote:<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
Not opposed to ditching segmented addressing at all.<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
We'd<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">need<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">ticket<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">for this<br class="">
<blockquote type="cite" class="">ASAP, though.<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
This whole conversation is predicated on:<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
- MPI supposedly supports segmented addressing<br class="">
<br class="">
<br class="">
- MPI_Aint is not sufficient for modern segmented<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
addressing<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">(i.e.,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">representing<br class="">
<blockquote type="cite" class="">an address that may not be in main RAM and is not<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mapped in<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">to<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">current<br class="">
<blockquote type="cite" class="">process' linear address space)<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
If we no longer care about segmented addressing, that<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
makes<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">whole<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">bunch of<br class="">
<blockquote type="cite" class="">BigCount stuff a LOT easier. E.g., MPI_Aint can<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
basically<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">be a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">non-segment-supporting address integer. AINT_DIFF and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
AINT_SUM<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">can<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">go<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">away,<br class="">
<blockquote type="cite" class="">too.<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
On Oct 24, 2019, at 5:35 PM, Jeff Hammond via<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mpiwg-large-counts <<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">[<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mailto:mpiwg-large-counts@lists.mpi-forum.org |<br class="">
mpiwg-large-counts@lists.mpi-forum.org ] > wrote:<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
Rolf:<br class="">
<br class="">
<br class="">
<br class="">
Before anybody spends any time analyzing how we handle<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
segmented<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">addressing, I<br class="">
<blockquote type="cite" class="">want you to provide an example of a platform where this<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">relevant.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">What<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">system can you boot today that needs this and what MPI<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
libraries<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">have<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">expressed<br class="">
<blockquote type="cite" class="">an interest in supporting it?<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
For anyone who didn't hear, ISO C and C++ have finally<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
committed to<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">twos-complement integers ( [<br class="">
<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">|<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">, [<br class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm |<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">] )<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">because<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">modern<br class="">
<blockquote type="cite" class="">programmers should not be limited by hardware designs<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
from<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">1960s.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">We<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">should<br class="">
<blockquote type="cite" class="">similarly not waste our time on obsolete features like<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
segmentation.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
Jeff<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
On Thu, Oct 24, 2019 at 10:13 AM Rolf Rabenseifner via<br class="">
</blockquote>
mpiwg-large-counts < [<br class="">
<blockquote type="cite" class="">mailto:mpiwg-large-counts@lists.mpi-forum.org |<br class="">
mpiwg-large-counts@lists.mpi-forum.org ] > wrote:<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">I think that changes the conversation entirely, right?<br class="">
</blockquote>
<br class="">
Not the first part, the state-of-current-MPI.<br class="">
<br class="">
It may change something for the future, or a new<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
interface<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">may<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">be<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">needed.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
Please, can you describe how MPI_Get_address can work<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
with<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">different variables from different memory segments.<br class="">
<br class="">
Or whether a completely new function or a set of<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
functions<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">is<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">needed.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
If we can still express variables from all memory<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
segments<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">as<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">input to MPI_Get_address, there may be still a way to<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
flatten<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">the result of some internal address-iquiry into a<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
flattened<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">signed integer with the same behavior as MPI_Aint today.<br class="">
<br class="">
If this is impossible, then new way of thinking and<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
solution<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">may be needed.<br class="">
<br class="">
I really want to see examples for all current stuff as<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
you<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mentioned in your last email.<br class="">
<br class="">
Best regards<br class="">
Rolf<br class="">
<br class="">
----- Original Message -----<br class="">
<blockquote type="cite" class="">From: "Jeff Squyres" < [ mailto:jsquyres@cisco.com |<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
jsquyres@cisco.com<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">] ><br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">To: "Rolf Rabenseifner" < [ mailto:<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de |<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">rabenseifner@hlrs.de ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
Cc: "mpiwg-large-counts" < [ mailto:<br class="">
</blockquote>
</blockquote>
mpiwg-large-counts@lists.mpi-forum.org |<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mpiwg-large-counts@lists.mpi-forum.org ] ><br class="">
Sent: Thursday, October 24, 2019 5:27:31 PM<br class="">
Subject: Re: [Mpiwg-large-counts] Large Count - the<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
principles for<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">counts,<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">sizes, and byte and nonbyte displacements<br class="">
</blockquote>
<br class="">
<blockquote type="cite" class="">On Oct 24, 2019, at 11:15 AM, Rolf Rabenseifner<br class="">
< [ mailto:rabenseifner@hlrs.de | rabenseifner@hlrs.de<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><mailto:<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">[<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mailto:rabenseifner@hlrs.de | rabenseifner@hlrs.de ]<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">wrote:<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
For me, it looked like that there was some<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
misunderstanding<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">of the concept that absolute and relative addresses<br class="">
and number of bytes that can be stored in MPI_Aint.<br class="">
<br class="">
...with the caveat that MPI_Aint -- as it is right now<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
--<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">does not<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">support<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">modern segmented memory systems (i.e., where you need<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
more<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">than a<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">small<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">number<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">of bits to indicate the segment where the memory<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
lives).<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
I think that changes the conversation entirely, right?<br class="">
<br class="">
--<br class="">
Jeff Squyres<br class="">
[ mailto:jsquyres@cisco.com | jsquyres@cisco.com ]<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<mailto: [<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">mailto:jsquyres@cisco.com | jsquyres@cisco.com ] ><br class="">
</blockquote>
<br class="">
--<br class="">
Dr. Rolf Rabenseifner . . . . . . . . . .. email [<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
mailto:<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">rabenseifner@hlrs.de |<br class="">
<blockquote type="cite" class="">rabenseifner@hlrs.de ] .<br class="">
High Performance Computing Center (HLRS) . phone<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
++49(0)711/685-65530<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">University of Stuttgart . . . . . . . . .. fax<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
++49(0)711 /<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">685-65832<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Head of Dpmt Parallel Computing . . . [<br class="">
</blockquote>
http://www.hlrs.de/people/rabenseifner |<br class="">
<blockquote type="cite" class="">www.hlrs.de/people/rabenseifner ] .<br class="">
Nobelstr. 19, D-70550 Stuttgart, Germany . . . .<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
(Office:<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Room<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">1.307)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">_______________________________________________<br class="">
mpiwg-large-counts mailing list<br class="">
[ mailto:mpiwg-large-counts@lists.mpi-forum.org |<br class="">
mpiwg-large-counts@lists.mpi-forum.org ]<br class="">
[<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">|<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
--<br class="">
<br class="">
<br class="">
Jeff Hammond<br class="">
[ mailto:jeff.science@gmail.com |<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
jeff.science@gmail.com ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">[ http://jeffhammond.github.io/ |<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
http://jeffhammond.github.io/ ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<br class="">
_______________________________________________<br class="">
mpiwg-large-counts mailing list<br class="">
[ mailto:mpiwg-large-counts@lists.mpi-forum.org |<br class="">
mpiwg-large-counts@lists.mpi-forum.org ]<br class="">
[<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">|<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
--<br class="">
Jeff Squyres<br class="">
[ mailto:jsquyres@cisco.com | jsquyres@cisco.com ]<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
--<br class="">
<br class="">
<br class="">
Jeff Hammond<br class="">
[ mailto:jeff.science@gmail.com |<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
jeff.science@gmail.com ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">[ http://jeffhammond.github.io/ |<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
http://jeffhammond.github.io/ ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">_______________________________________________<br class="">
mpiwg-large-counts mailing list<br class="">
[ mailto:mpiwg-large-counts@lists.mpi-forum.org |<br class="">
mpiwg-large-counts@lists.mpi-forum.org ]<br class="">
[<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">|<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts ]<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
_______________________________________________<br class="">
mpiwg-large-counts mailing list<br class="">
mpiwg-large-counts@lists.mpi-forum.org<br class="">
<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
--<br class="">
Dr. Rolf Rabenseifner . . . . . . . . . .. email<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">High Performance Computing Center (HLRS) . phone<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
++49(0)711/685-65530 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">University of Stuttgart . . . . . . . . .. fax ++49(0)711<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
/<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">685-65832 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Head of Dpmt Parallel Computing . . .<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
www.hlrs.de/people/rabenseifner .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office:<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
Room<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">1.307) .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
--<br class="">
Dr. Rolf Rabenseifner . . . . . . . . . .. email<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">High Performance Computing Center (HLRS) . phone<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
++49(0)711/685-65530 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
685-65832 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Head of Dpmt Parallel Computing . . .<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
www.hlrs.de/people/rabenseifner .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office:<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
Room<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">1.307) .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
--<br class="">
Dr. Rolf Rabenseifner . . . . . . . . . .. email<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">High Performance Computing Center (HLRS) . phone<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
++49(0)711/685-65530 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
685-65832 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Head of Dpmt Parallel Computing . . .<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
www.hlrs.de/people/rabenseifner<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
1.307) .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
--<br class="">
Dr. Rolf Rabenseifner . . . . . . . . . .. email<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
rabenseifner@hlrs.de<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">High Performance Computing Center (HLRS) . phone<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
++49(0)711/685-65530 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
685-65832 .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Head of Dpmt Parallel Computing . . .<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
www.hlrs.de/people/rabenseifner<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br class="">
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
1.307) .<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
</blockquote>
_______________________________________________<br class="">
mpiwg-large-counts mailing list<br class="">
mpiwg-large-counts@lists.mpi-forum.org<br class="">
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts<br class="">
<br class="">
</blockquote>
<br class="">
<br class="">
--<br class="">
Jeff Hammond<br class="">
jeff.science@gmail.com<br class="">
http://jeffhammond.github.io/<br class="">
</blockquote>
<br class="">
--<br class="">
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de<br class="">
</blockquote>
</blockquote>
.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 .<br class="">
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 .<br class="">
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<br class="">
</blockquote>
</blockquote>
.<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .<br class="">
<br class="">
<br class="">
<br class="">
</blockquote>
<br class="">
--<br class="">
Jeff Hammond<br class="">
jeff.science@gmail.com<br class="">
http://jeffhammond.github.io/<br class="">
</blockquote>
<br class="">
--<br class="">
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de .<br class="">
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 .<br class="">
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 .<br class="">
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner .<br class="">
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .<br class="">
<br class="">
</blockquote>
<br class="">
<br class="">
--<span class="Apple-converted-space"> </span><br class="">
Jeff Hammond<br class="">
jeff.science@gmail.com<br class="">
http://jeffhammond.github.io/<br class="">
</blockquote>
<br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">--<span class="Apple-converted-space"> </span></span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Dr.
Rolf Rabenseifner . . . . . . . . . .. email<span class="Apple-converted-space"> </span></span><a href="mailto:rabenseifner@hlrs.de" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">rabenseifner@hlrs.de</a><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">High
Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 .</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">University
of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 .</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Head
of Dpmt Parallel Computing . . .<span class="Apple-converted-space"> </span></span><a href="http://www.hlrs.de/people/rabenseifner" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">www.hlrs.de/people/rabenseifner</a><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Nobelstr.
19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">mpiwg-large-counts
mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<a href="mailto:mpiwg-large-counts@lists.mpi-forum.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">mpiwg-large-counts@lists.mpi-forum.org</a><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts</a></div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>