[mpiwg-tools] Embiggening for Tools Chapter

[schulzm at in.tum.de]

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: schulzm at in.tum.de


> On 21. Jan 2020, at 08:41, Marc-André Hermanns via mpiwg-tools <mpiwg-tools at lists.mpi-forum.org> 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
> hermanns at itc.rwth-aachen.de
> www.itc.rwth-aachen.de
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20200121/0a29b50d/attachment-0001.html>