You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Giving applications that want to map between a 1 rank/core policy to a 1 rank/NUMA policy an on-numa-node communicator would be a good choice for the next implemented type in QUO_get_comm_by_type. This is a good choice in my mind because it alleviates the need for OpenMP applications to deal with first touch and keeps the cores/rank at a level in which on-node gathers/scatters are manageable.
Not necessarily a high priority issue, but if I had a say in which one gets implemented next, that would be my vote.
Edit: grammar
The text was updated successfully, but these errors were encountered:
Giving applications that want to map between a 1 rank/core policy to a 1 rank/NUMA policy an on-numa-node communicator would be a good choice for the next implemented type in
QUO_get_comm_by_type
. This is a good choice in my mind because it alleviates the need for OpenMP applications to deal with first touch and keeps the cores/rank at a level in which on-node gathers/scatters are manageable.Not necessarily a high priority issue, but if I had a say in which one gets implemented next, that would be my vote.
Edit: grammar
The text was updated successfully, but these errors were encountered: