Skip to content
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

Avoid piracy and racey method shadowing #118

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jpsamaroo
Copy link

@jpsamaroo jpsamaroo commented Sep 30, 2024

This PR implements a mechanism for utilizing the selected backend to create a dispatchable key (turning "cuda" into Val{:cuda}()), so that extensions do not need to shadow/pirate JACC's own methods. This should make it safe to load CUDA, AMDGPU, and oneAPI all at once (or any such combination), yet have things still dispatch correctly based on the selected backend.

Unfortunately, this cannot work for JACC.Array as-is, because extensions are loaded after __init__ is called. So instead, I propose moving the setting of JACC.Array into an init() function that users must call to initialize JACC. There is not really any nice way to do this that I can think of - maybe if module property access becomes something we can control (like how we can overload getproperty), then it will be possible to remove the need for init(). Fixed!

Although this does work for using AMDGPU, JACC for me locally, I still have to wire up the tests for this, and I haven't tested any of the functionality (as my ROCm libraries are a mess on my local system). Hence this is currently a draft PR.

This PR implements a mechanism for utilizing the selected backend to
create a dispatchable key (turning "cuda" into `Val{:cuda}()`), so that
extensions do not need to shadow/pirate JACC's own methods. This should
make it safe to load CUDA, AMDGPU, and oneAPI all at once (or any such
combination), yet have things still dispatch correctly based on the
selected backend.
@jpsamaroo
Copy link
Author

Note: this is an alternative to #114, which is similar in scope, but also does not resolve the issues around JACC.Array. I think this PR's approach is a bit simpler, and doesn't require eval'ing another global into the JACC module (which is what prevents JACC from being precompile-able).

@jpsamaroo
Copy link
Author

...and I just realized that it's also an alternative to #86, which I think goes much further to resolve the issues with JACC.Array and is a more correct solution.

@jpsamaroo jpsamaroo marked this pull request as ready for review October 3, 2024 17:42
@williamfgc
Copy link
Collaborator

Test this please

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants