Hi Marc-Andre, Thanks for the starting the discussion - given the fact that we rarely have a variable using more than “1” in the alloc calls, I personally think MPI_Count is overkill. Also, the parameter has a bit of a different nature, as it is an out, i.e., the MPI Library sets it, which makes it IMHO less problematic. I would, therefore, vote for not embiggening MPI_T. Just my 2c, Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: [email protected]

On 21. Jan 2020, at 08:41, Marc-André Hermanns via mpiwg-tools <[email protected]> wrote:

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 [email protected] www.itc.rwth-aachen.de

_______________________________________________ mpiwg-tools mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools