-
Notifications
You must be signed in to change notification settings - Fork 18
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
Encapsulate Storage_base class #528
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
0dd1be9
to
97a2597
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev-master #528 +/- ##
==============================================
- Coverage 23.64% 23.58% -0.07%
==============================================
Files 211 211
Lines 44911 44926 +15
Branches 15039 14018 -1021
==============================================
- Hits 10620 10595 -25
- Misses 32641 32664 +23
- Partials 1650 1667 +17 ☔ View full report in Codecov by Sentry. |
IvanaGyro
commented
Dec 2, 2024
IvanaGyro
commented
Dec 2, 2024
`Storage::release()` serves for the function converting Storage and Tensor to the numpy array. The reason for implementing this method is that we are encapsulating Storage and the relative classes, which mean we don't want other classes or functions to directly access the member variables. This is just a temporary solution and will be removed when we use std::vector as the underlying storage because it is impossible to make std::vector drops its ownership of the underlying storage.
The size of Scalar is small, so it's cheap for creating a temporary Storage containing only a copy of the value of Scalar. This change is a step toward encapsulating the classes related to Storage.
97a2597
to
36f65fd
Compare
With the current class definition, developers are able to change the variable storing the size of the storage without allocating the underlying storage, which potentially causes memory leaks. To ensure there will be no surprising behavior caused by directly accessing the variables of Storage_base, all variables of Stroage_base are moved to its subclass, StorageImplementation<DType>, and are set as private. All functions outside of StorageImplementation<DType> should access the value of the variable via the getters. The next step in refactoring the components related to Storage is to remove the Storage_base class.
We can check whether HPTT is enabled from the compiler definitions in compile_commands.json.
36f65fd
to
09b2c37
Compare
hunghaoti
approved these changes
Dec 25, 2024
hunghaoti
approved these changes
Dec 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The first two commits are the same as #525. Please start to review from the third commit.
There are too many files changed to review. I leave comments on the changed lines which are not trivially renaming the variables. You can just review those parts.
With the current class definition, developers are able to change the variable storing the size of the storage without allocating the underlying storage, which potentially causes memory leaks.
To ensure there will be no surprising behavior caused by directly accessing the variables of Storage_base, all variables of Stroage_base are moved to its subclass, StorageImplementation, and are set as private. All functions outside of StorageImplementation should access the value of the variable via the getters.
The next step in refactoring the components related to Storage is to remove the Storage_base class.
Test result
This PR breaks no tests with CUDA, cuQuantum, cuTENSOR, MKL, CUTT, and HPTT enabled.