<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 Marc-Andre,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I would, therefore, vote for not embiggening MPI_T.</div><div class=""><br class=""></div><div class="">Just my 2c,</div><div class=""><br class=""></div><div class="">Martin</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class="">
<div dir="auto" style="font-family: Helvetica; font-size: 14px; 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; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); 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 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="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 dir="auto" 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 dir="auto" style="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;">—<br class="">Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems<br class="">Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching<br class="">Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)<br class=""><a href="mailto:schulzm@in.tum.de" class="">Email: schulzm@in.tum.de</a><br class=""><br class=""></div></div></div></div></div></div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 21. Jan 2020, at 08:41, Marc-André Hermanns via mpiwg-tools <<a href="mailto:mpiwg-tools@lists.mpi-forum.org" class="">mpiwg-tools@lists.mpi-forum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear all,<br class=""><br class="">(let's use this mailing list for more than just announcements ;-) ---<br class="">and please keep Jeff and Martin R. in the loop, as I don't know<br class="">whether they [still] subscribe to the list)<br class=""><br class="">Sorry for being a bit late with this discussion. Today is the deadline<br class="">for the Embiggening check through all the chapters, and I finally<br class="">finished the tools chapter.<br class=""><br class="">*TL;DR:*<br class=""><br class="">The `handle_alloc` functions are the only ones being embiggened. Do<br class="">they need to be? Are these enough?<br class=""><br class=""><br class="">*Details below:*<br class=""><br class="">There we currently see two situations where we have an "Embiggening"<br class="">taking place:<br class=""><br class="">mpi_t_cvar_handle_alloc<br class="">mpi_t_pvar_handle_alloc<br class=""><br class="">With the paramter `count` being a POLYTOOLS_NUM_ELEM, leading to two<br class="">additional calls with `_l` suffix where said count is not an `int` but<br class="">an `MPI_Count`.<br class=""><br class="">The description of `count` in both calls is as follows:<br class="">"number of elements used to represent this variable<br class="">(non-negative integer)"<br class=""><br class="">I was wondering now: Is this `count` to be an `MPI_Count` necessary? I<br class="">am not against it, I just want to make sure we have a strong argument<br class="">for it. If we ever have a performance or config variable that in<br class="">itself contains more than 2,147,483,647 values (per instance), that<br class="">variable in itself might be the performance bottleneck we are trying<br class="">to uncover ;-)<br class=""><br class="">If we argue for having this `count` as an `MPI_Count`, to make things<br class="">future proof. What about the calls to<br class=""><br class="">mpi_t_cvar_get_num<br class="">mpi_t_pvar_get_num<br class=""><br class="">?<br class=""><br class="">I do see a difference in defining a single variable with lots of<br class="">entries and defining lots of variables with single values, so I am<br class="">also not against this distinction. I just want to make sure, we don't<br class="">/miss out/ on these call, just because their parameter names are not<br class="">`count` but `num_cvars` and `num_pvars`, respectively.<br class=""><br class="">If we do change these, however, we'd have to update all the calls that<br class="">take an `index` value, too, as that `index` is between 0 and<br class="">`num_pvar` and `num_cvar`, respectively. And that's basically every<br class="">call ;-)<br class=""><br class=""><br class="">So, are we good with how things are defined at the moment? Should we<br class="">adapt? In which direction?<br class=""><br class="">Any thoughts on this?<br class=""><br class="">Cheers,<br class="">Marc-Andre<br class=""><br class="">-- <br class="">Dr. rer. nat. Marc-André Hermanns<br class=""><br class="">IT Center<br class="">Group: High Performance Computing<br class="">Division: Computational Science and Engineering<br class="">RWTH Aachen University<br class="">Seffenter Weg 23<br class="">52074 Aachen<br class="">Phone: +49 241 80-24381<br class=""><a href="mailto:hermanns@itc.rwth-aachen.de" class="">hermanns@itc.rwth-aachen.de</a><br class="">www.itc.rwth-aachen.de<br class=""><br class="">_______________________________________________<br class="">mpiwg-tools mailing list<br class="">mpiwg-tools@lists.mpi-forum.org<br class="">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools<br class=""></div></div></blockquote></div><br class=""></div></body></html>