[mpiwg-tools] Embiggening for Tools Chapter

Marc-André Hermanns hermanns at itc.rwth-aachen.de
Tue Jan 21 01:41:25 CST 2020

Dear all,

(let's use this mailing list for more than just announcements ;-) ---
and please keep Jeff and Martin R. in the loop, as I don't know
whether they [still] subscribe to the list)

Sorry for being a bit late with this discussion. Today is the deadline
for the Embiggening check through all the chapters, and I finally
finished the tools chapter.


The `handle_alloc` functions are the only ones being embiggened. Do
they need to be? Are these enough?

*Details below:*

There we currently see two situations where we have an "Embiggening"
taking place:


With the paramter `count` being a POLYTOOLS_NUM_ELEM, leading to two
additional calls with `_l` suffix where said count is not an `int` but
an `MPI_Count`.

The description of `count` in both calls is as follows:
"number  of  elements  used  to  represent  this  variable
(non-negative integer)"

I was wondering now: Is this `count` to be an `MPI_Count` necessary? I
am not against it, I just want to make sure we have a strong argument
for it. If we ever have a performance or config variable that in
itself contains more than 2,147,483,647 values (per instance), that
variable in itself might be the performance bottleneck we are trying
to uncover ;-)

If we argue for having this `count` as an `MPI_Count`, to make things
future proof. What about the calls to



I do see a difference in defining a single variable with lots of
entries and defining lots of variables with single values, so I am
also not against this distinction. I just want to make sure, we don't
/miss out/ on these call, just because their parameter names are not
`count` but `num_cvars` and `num_pvars`, respectively.

If we do change these, however, we'd have to update all the calls that
take an `index` value, too, as that `index` is between 0 and
`num_pvar` and `num_cvar`, respectively. And that's basically every
call ;-)

So, are we good with how things are defined at the moment? Should we
adapt? In which direction?

Any thoughts on this?


Dr. rer. nat. Marc-André Hermanns

IT Center
Group: High Performance Computing
Division: Computational Science and Engineering
RWTH Aachen University
Seffenter Weg 23
52074 Aachen
Phone: +49 241 80-24381
hermanns at itc.rwth-aachen.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5336 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20200121/f52b6866/attachment.p7s>

More information about the mpiwg-tools mailing list