Hi everyone,
This is a reminder of our regularly scheduled call today January 30 at
8 am Pacific / 11 am Eastern / 5pm CET.
Webex Info:
https://github.com/mpiwg-tools/mpi-standard/wiki
*NOTE*: The WebEx information for 2020 changed and is updated in the
mpi-standard wiki. You have to be logged into Github *and* have to
have access to the private Tools WG repositories. If you need access
contact me.
Agenda:
-------
- What to do with Embiggened(tm) calls
- Preparations for Spring meeting.
Cheers,
Marc-André
--
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(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
Dear all,
sorry, but I will have to cancel for today Jan 23, 2020.
The past week has been really busy, so I only got to focus on Tools
Chapter issues and I didn't progress on any topic of our current
discussion.
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(a)itc.rwth-aachen.de
www.itc.rwth-aachen.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(a)in.tum.de
> On 21. Jan 2020, at 08:41, Marc-André Hermanns via mpiwg-tools <mpiwg-tools(a)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(a)itc.rwth-aachen.de
> www.itc.rwth-aachen.de
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools(a)lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
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(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
Dear all,
unfortunately I didn't get to work on specific WG topics this week,
so there is no real update to talk about.
Therefore, I'd cancel today's meeting. I hope to have updates for next
week.
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(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
Hi everyone,
This is a reminder of our regularly scheduled call today January
9 at 8 am Pacific / 11 am Eastern / 5pm CET.
Webex Info:
https://github.com/mpiwg-tools/mpi-standard/wiki
*NOTE*: The WebEx information for 2020 changed and is updated in the mpi-standard wiki. You have
to be logged into Github *and* have to have access to the private
Tools WG repositories. If you need access contact me.
Agenda:
-------
- Brief discussion of our current topics
Cheers,
Marc-André
Sent from phone.
--
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(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
