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

[GPU] Use array for tracking memory usage instead of map #25269

Merged

Conversation

ialbrecht
Copy link
Contributor

Details:

  • Any additional locking and synchronization on memory allocation might have negative impact on MT execution.
  • std::map has very slow access are requires lock on every access. We can use std::array instead to hold compile time known number of buckets.
  • array container has lower access latency and memory overhead.
  • We might me able to remove mutex lock on stat collection.

@ialbrecht ialbrecht requested review from a team as code owners June 27, 2024 20:50
@github-actions github-actions bot added the category: GPU OpenVINO GPU plugin label Jun 27, 2024
@sys-openvino-ci sys-openvino-ci added the ExternalPR External contributor label Jun 27, 2024
@rkazants
Copy link
Contributor

build_jenkins

@rkazants rkazants added the ExternalIntelPR External contributor from Intel label Jun 28, 2024
@rkazants
Copy link
Contributor

Hi @ialbrecht,
any data with concrete numbers on how it can affect MT execution in your case?

@ialbrecht
Copy link
Contributor Author

Hi @ialbrecht, any data with concrete numbers on how it can affect MT execution in your case?

We had benchmarks were memory allocation was on the critical performance path and we were looking at all possible ways to optimize it.

@vladimir-paramuzov vladimir-paramuzov changed the title Use array for tracking memory usage instead of map [GPU] Use array for tracking memory usage instead of map Jul 3, 2024
`std::map` has very slow access are requires lock on every access. We can use `std::array` instead to hold compile time known number of buckets. This method should have less latency and memory overhead, as well as possibly no lock on access.
No need to lock mutex to update atomic values
Make sure atomic values are zero initialized.
`fetch_add` returns old value, therefore we need to increment current memory usage value before storing current max.
@vladimir-paramuzov
Copy link
Contributor

build_jenkins

@vladimir-paramuzov vladimir-paramuzov added this pull request to the merge queue Jul 29, 2024
Merged via the queue into openvinotoolkit:master with commit 131c944 Jul 29, 2024
109 checks passed
@vladimir-paramuzov vladimir-paramuzov added this to the 2024.4 milestone Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: GPU OpenVINO GPU plugin ExternalIntelPR External contributor from Intel ExternalPR External contributor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants