-
Notifications
You must be signed in to change notification settings - Fork 79
Unified memory allocations #630
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
Conversation
|
Your PR no longer requires formatting changes. Thank you for your contribution! |
|
Perhaps we can make this backwards portable and add it to 0.9 first? |
|
Thanks once we have it merged in 0.9, please update this PR so that the implementations match. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #630 +/- ##
==========================================
+ Coverage 47.54% 51.24% +3.70%
==========================================
Files 22 21 -1
Lines 1729 1610 -119
==========================================
+ Hits 822 825 +3
+ Misses 907 785 -122 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
ready to merge? |
Add to docs
Also remove unused file
98ba890 to
7d5f80c
Compare
Co-authored-by: Christian Guinard <[email protected]>
Close #601
@vchuravy The idea is that you request unified if you want to allocate some memory with unified memory to speed up operations that necessitate CPU access (like 1d reduce result or the indices container in
findall). Otherwise just use the default storage type. Backends would have to add support for theunifiedkwarg.