Team argument in collective operations

[naveen-rn]

I happen to notice that the new proposed all-reduce operations support C11 routines. So, I would expect that the team arguments are the first arguments in these routines. To be consistent across all collectives, the team arguments must to the first argument rather than the last as it is proposed now.

This requirement is same as the order of the context argument in current OpenSHMEM 1.4 RMA and AMOs.

[jdinan]

We needed this with contexts because the generic routines span operations with and without an explicit context argument. I don't think that's the case with teams, right? So at least from a C11 generic selection point of view, it shouldn't matter where we put the team argument. Although, there may be a consistency argument for mirroring what we did with the point-to-point APIs.

[gmegan]

Hmm, so the reason these ended up this way is to mirror the ordering of arguments for the active set versions of the collectives, which had the active set params at the end of the list. In the other routines, I think the general pattern was to put inputs first and outputs last.

So looking at all the routines that take a team param, the placement of the team param is:

team_my_pe : only param team_n_pes : only param team_translate_pe : source (input pe) team is first, dest (output pe) team is last teamsplit : input (parent) team is first, output (child) team is last team_destroy : only param team_ctx_create : input team is first param, output context is last ctx_get_team : input context is first param, output team is last all p2p with ctx : input context is first param team_sync : only param team_broadcast : input team is last param team[f]collect* : input team is last param team__ to_all : input team is last param team_all_to_all* : input team is last param

The collectives match each other, but don't really match the pattern of the other team/context routines where the team/context comes first unless it is an output.

So the only reason the collectives were different is so that they match the active set routines. But if the active set routines are already deprecated, I wouldn't see much reason to leave the team param in a matching location since we would not really want people using both types of routines anyway.

[nspark]

I can't make the call today, so I wanted to drop a thought or two here. I don't think it affects the C11 generic machinery whether the shmem_team_t argument is first or last. (At first, I thought it was a problem if it came last, but I think we've previously resolved the issue I thought this would encounter.)

I think my preference is for the shmem_team_t argument to be the first argument. I think of these calls as C-style "object methods", and my preference there is for the "object" on which the method is (notionally) called to be the first argument to the function.