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

Add peak_memory_usage to all nvbench benchmarks #10528

Open
vyasr opened this issue Mar 28, 2022 · 10 comments
Open

Add peak_memory_usage to all nvbench benchmarks #10528

vyasr opened this issue Mar 28, 2022 · 10 comments
Assignees
Labels
0 - Backlog In queue waiting for assignment feature request New feature or request good first issue Good for newcomers libcudf Affects libcudf (C++/CUDA) code. Performance Performance related issue
Milestone

Comments

@vyasr
Copy link
Contributor

vyasr commented Mar 28, 2022

Update (2023-12-05):
Adding peak_memory_usage to nvbenchmarks can be accomplished with this pattern:

auto const mem_stats_logger = cudf::memory_stats_logger(); 

state.exec( ... );

state.add_buffer_size(
    mem_stats_logger.peak_memory_usage(), 
    "peak_memory_usage", 
    "peak_memory_usage"
);

Please consult the cuIO benchmarks for how to add peak memory tracking. If we are tracking peak memory usage as well as bytes per second, then we can estimate memory footprint across the libcudf API.

Original issue:
#7770 added support for peak memory usage to cuIO benchmarks using rmm's statistics_resource_adapter. It would be nice to be able to expand that to all of our benchmarks so that we could more easily detect regressions in memory usage. This would be particularly useful for the Dask cuDF team, which is always looking to identify bottlenecks from memory usage. There was already discussion of doing this in #7770, so we should investigate following up now.

@vyasr vyasr added feature request New feature or request Performance Performance related issue labels Mar 28, 2022
@vyasr
Copy link
Contributor Author

vyasr commented Mar 28, 2022

CC @galipremsagar who was interested in this data.

@devavret it looks like you made this very easy with the memory_stats_logger? @harrism would you still be in favor of this?

@harrism
Copy link
Member

harrism commented Mar 29, 2022

@harrism would you still be in favor of this?

I don't have a reason not to support this. However it may not benefit the utility of all benchmarks. Does it impact CI benchmark throughput?

@jrhemstad
Copy link
Contributor

I am reluctant to add this new functionality based on Google Benchmark when we are trying to phase that out.

I would support adding this as a feature to benchmarks ported to NVBench.

@vyasr
Copy link
Contributor Author

vyasr commented Mar 29, 2022

@PointKernel I notice that you're already doing this in #10248 with NVBench benchmarks. It looks like it's no more complex than incorporating the resource adapter into GBench benchmarks?

@PointKernel
Copy link
Member

It looks like it's no more complex than incorporating the resource adapter into GBench benchmarks?

Right. It's effortless with the help of memory_stats_logger. Only two lines to be added:

auto mem_stats_logger = cudf::memory_stats_logger(); // init stats logger
state.exec([&](nvbench::launch& launch) {
  target_kernel();
});
state.add_element_count(mem_stats_logger.peak_memory_usage(), "Peak Memory"); // report peak memory usage to nvbench

@vyasr
Copy link
Contributor Author

vyasr commented Mar 29, 2022

So then maybe making this change is independent of whether a benchmark has been switch from GBench to NVBench? It seems like we could add this now, then when a project switches from GBench to NVBench the only required change are to switch stat.add_element_count( for state.counters["peak_memory_usage"].

@jrhemstad
Copy link
Contributor

So then maybe making this change is independent of whether a benchmark has been switch from GBench to NVBench?

There's also the parsing and reporting side that will be different.

I don't want to keep building things on top of GBench when I'm actively trying to get people to switch to NVbench.

@github-actions
Copy link

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

@github-actions
Copy link

This issue has been labeled inactive-90d due to no recent activity in the past 90 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed.

@GregoryKimball GregoryKimball added 0 - Backlog In queue waiting for assignment libcudf Affects libcudf (C++/CUDA) code. and removed inactive-30d labels Nov 21, 2022
@GregoryKimball GregoryKimball added the good first issue Good for newcomers label Dec 5, 2023
@GregoryKimball GregoryKimball moved this to Needs owner in libcudf Dec 5, 2023
@GregoryKimball GregoryKimball changed the title Add peak memory tracking to all benchmarks Add peak_memory_usage to all nvbench benchmarks Dec 5, 2023
@GregoryKimball GregoryKimball removed the status in libcudf Mar 1, 2024
@vyasr
Copy link
Contributor Author

vyasr commented May 17, 2024

@GregoryKimball do you think this is worth doing systematically for all benchmarks, or something we can add on a case by case basis as the need arises? If the latter, I would vote that we close this issue and just add this when we are benchmarking specific functionality.

@kingcrimsontianyu kingcrimsontianyu self-assigned this Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 - Backlog In queue waiting for assignment feature request New feature or request good first issue Good for newcomers libcudf Affects libcudf (C++/CUDA) code. Performance Performance related issue
Projects
Status: No status
Development

No branches or pull requests

6 participants