-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cray OpenSHMEM-X 11 - do not merge #22
base: master
Are you sure you want to change the base?
Conversation
Here is an example of an error in the Cray header: #define SHMEM_C_TEAM_REDUCE_ALL(TYPENAME,OP,TYPE) \
EXPORT void shmem_##TYPENAME##_##OP##_reduce(shmem_team_t team, TYPE *dest, \
_CNST TYPE *source, _SIZ_T nreduce) The OpenSHMEM 1.5 specification says
|
My hack for
|
I guess changing the type of a team also matters:
|
Definitely! This is something we should handle in the build system, with a configure-style check. Or we just advocate to implementers to stop with the integer-handle obsession, maybe pointing to our MPI-5 efforts. In the particular case of Cray, we have a very simple point to make: they already use pointers for contexts, why don't they just do the same for teams? Moreover, |
I think you should just include shmem.h and use |
Treating |
That's not the point I was trying to make. What I meant is that if Cray switches to pointers, then the team handle is the same size as they have now in most 64bit platforms they care.
This is an issue/limitation of the CFFI package. I never figured out how to tell CFFI this type maybe a pointer or an integral type. And if you assume one or the other, then at some point something breaks (in the sense that the generated C code is broken). |
is it possible to use something like this? typedef union { int i; void* p; intptr_t ip; } shmem4py_team_t; |
I've tried that, but they another issues will arise. For example, CFFI would not allow you to compare handles by equality, pretty much as you cannot compare two struct values in C. |
sure but these are the internal representation of an opaque type so why should CFFI need to do that? if it needs that, i can do the comparison using something other than |
what is |
nevermind, i RTFM'd and it's impossible
|
Jeff, I have tried hard, trust me. I already hit this issue in our first failed attempt to NVSHMEM, because of the type of PS: An OpenSHMEM ABI spec would be even simpler than the MPI case, the API is way smaller. Using pointers instead of integers for handles is a necessary step for that. |
i fixed all the compilation errors with shmem4py.api.c by explicitly casting team arguments (under the assumption that |
This allows for OpenSHMEM implementations declaring ctx/team types as either a pointer types or an integral types. Declaring `shmem_{ctx|team}_t` as an opaque struct type has an annoying side-effect: now ctx/team handles can no longer be compared for equality. Therefore, add a couple auxiliary functions `eq_{ctx|team}` to compare handles for equality. Additionally, in case we need them in the future, add functions to convert to/from integer values.
81ead30
to
f153f30
Compare
@jeffhammond I force-pushed your branch. Can you give it a new try? Do you plan to somehow report upstream all nits we run into? So far I can count the following:
|
Builds fine but crashes because the implementation of teams is buggy.
|
This is a record of all the hacks I am doing for LUMI due to Cray OpenSHMEM-X 11 not being standard-compliant.
Currently, I am able to build with warnings. The most egregious hack is due to the Cray header declaring reductions to return
void
notint
.I think the following has a workaround in the source already but I guess I didn't activate it properly.