search

hpc / quo-vadis

A cross-stack coordination layer to dynamically map runtime components to hardware resources
BSD 3-Clause "New" or "Revised" License
7 stars 4 forks source link

Improve ksplit and affinity preserving mapping. #118

Closed samuelkgutierrez closed 2 months ago

samuelkgutierrez commented 2 months ago
andreapiacentini commented 2 months ago

AP = Affinity Preserving and Andrea Piacentini. Nomen Omen ! :-)

samuelkgutierrez commented 2 months ago

I love it! Henceforth, I vote that the Affinity Preserving mapper be known as the Andrea Piacentini mapper, in your honor :). It has a nicer ring to it. I hope you are doing well, sir.

samuelkgutierrez commented 2 months ago

@GuillaumeMercier, I think qvi_scope_ksplit() is ready for consideration in your threading work. Please see tests/test-mpi-scope-ksplit.cc as an example on how to use it.

GuillaumeMercier commented 2 months ago

@samuelkgutierrez : I will try this but I wonder why you changed the interface?

  1. The new one is very C++ oriented and we might want to keep a C one
  2. The former list of arguments was just perfect for my needs. Actually I think it could be called directly in my example which mean that you pretty much implemented qv_thread_scope_split(_at) (which is a good thing because I've been stuck on it for way too long now).

As for the current implementation:

  1. you use a qvi_scope_split_agg_s structure and not a qvi_scope_coll_data_s one. I wonder why since multiple processes may call this ksplit routine.
  2. You force QV_HW_OBJ_LAST in the splitagg_init call and I'm not sure why. Wouldn't be more flexible to pass an object type that is taken as an argument to the function (as with the former interface).

I'd like to discuss these points at today's meeting if that's OK with you.