[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.
*TL;DR:*
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:
mpi_t_cvar_handle_alloc
mpi_t_pvar_handle_alloc
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
mpi_t_cvar_get_num
mpi_t_pvar_get_num
?
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?
Cheers,
Marc-Andre
--
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
www.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