fix(primbench): `m_last_bytes_per_second` was always zero, ruining autotuning by MyNameIsTrez · Pull Request #11760 · ROCm/rocm-libraries

MyNameIsTrez · 2026-09-07T14:38:32Z

Motivation

JIRA ID : EXSWSTRHPC-322

m_last_bytes_per_second was always zero, ruining autotuning.

Additionally, some rocPRIM benchmarks (such as projects/rocprim/benchmark/benchmark_device_segmented_reduce.hpp) mistakenly called state.run() multiple times during tuning to test different segment sizes. This caused the bytes/sec returned to Kernel Tuner to be inaccurate and printed the same specialization multiple times to the terminal, which was very confusing.

Technical Details

The m_last_bytes_per_second variable is read by rocprim/tuning/tuner/templates/common/base.cpp.jinja2:

executor.run();

// Return the time as milliseconds per GiB.
return (1000 * primbench::GiB) / executor.get_last_bytes_per_second();

This problem was hidden because the autotuning system always picked the existing default config. By passing --exclude-default-config to run_tuning.py I told it not to use rocPRIM's default config. As expected, this caused a random, slow config to be output, as Kernel Tuner thought every config had an identical speed (m_last_bytes_per_second).

To prevent downstream autotuning issues, primbench.hpp was updated to explicitly forbid calling state.run() more than once per state object, matching the existing set_items behavior.

Test Plan

Here are the commands I ran while following the instructions in rocprim/tuning/README.md:

# Change directory 
cd projects/rocprim/tuning

# Activate virtual environment
python -m venv .venv
source .venv/bin/activate

# Install dependencies
pip3 install -i https://test.pypi.org/simple hip-python
pip3 install jinja2 kernel-tuner numpy

# Run tuning, using Ctrl+\ to stop the process once it finished outputting the first JSON file
rm -f output/device_merge_gfx90a_int128_t_cache.json && \
  ./run_tuning.py --algo-regex device_merge --seed 42

# Generate configuration
./confgen/generate.py \
  --input output/device_merge_gfx90a_int128_t_cache.json \
  --output foo --map-gfx gfx90a mi210

To verify the new safeguard, I also intentionally modified shared/primbench/examples/hip/copy_benchmark.cpp to call state.run() twice in succession.

Test Result

I looked at the terminal output, JSON output, and generated config to confirm the generated config now always matches the fastest specialization.

I also confirmed that my test modification in copy_benchmark.cpp successfully threw the "Error: Can't call run() twice" error and cleanly aborted execution as intended.

I also manually checked some specializations of the changed benchmark, to see if the results are the same, and they seemed to be. There is some run-to-run variance, especially with the segmented ones, but that was the same for both versions of the benchmarks.

Submission Checklist

Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

therock-pr-bot · 2026-09-07T15:05:11Z

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	⚠️ Warning	Error: Source/code files changed without an accompanying unit test. Expected: add at least one test file named like `test_<name>.py` / `test_<name>.cpp` (or `<name>_test.`). Current:* code file(s) changed: `projects/rocprim/benchmark/benchmark_device_histogram.hpp`, `projects/rocprim/benchmark/benchmark_device_segmented_radix_sort_keys.hpp`, `projects/rocprim/benchmark/benchmark_device_segmented_radix_sort_pairs.hpp`, `projects/rocprim/benchmark/benchmark_device_segmented_reduce.hpp`, `projects/rocprim/benchmark/benchmark_device_segmented_scan.hpp` (+1 more); no test file found
🔎 pre-commit	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—
🤖 therock-pr-bot	✅ Pass	—

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

therock-pr-bot · 2026-09-07T15:05:13Z

🎉 All checks passed! This PR is ready for review.

NguyenNhuDi

This lgtm, however I think prechckin is failing because of some clang-format stuff is needed.

…totuning I followed the instructions in projects/rocprim/tuning/README.md to confirm that the generated default config now matches the fastest specialization. The reason this problem was hidden is because the autotuning system always picked the existing default config, which was already the fastest specialization. By passing `--exclude-default-config` to `run_tuning.py` the autotuning system before this fix commit would output terribly slow configs.

In rocPRIM there are several benchmarks which call `state.run()` multiple times during tuning, like `projects/rocprim/benchmark/benchmark_device_segmented_reduce.hpp` calling it for 5 different segment sizes. This caused the bytes/sec that was returned to Kernel Tuner to be inaccurate, and for the same specialization to be printed 5x in the terminal, which was very confusing.

NguyenNhuDi

This still LGTM. However due to the coming 10.1 snap we should refrain from merging until after.

fix(primbench): `m_last_bytes_per_second` was always zero, ruining autotuning (#11760) ## Motivation JIRA ID : EXSWSTRHPC-322 `m_last_bytes_per_second` was always zero, ruining autotuning. Additionally, some rocPRIM benchmarks (such as `projects/rocprim/benchmark/benchmark_device_segmented_reduce.hpp`) mistakenly called `state.run()` multiple times during tuning to test different segment sizes. This caused the bytes/sec returned to Kernel Tuner to be inaccurate and printed the same specialization multiple times to the terminal, which was very confusing. ## Technical Details The `m_last_bytes_per_second` variable is read by [rocprim/tuning/tuner/templates/common/base.cpp.jinja2](https://github.com/ROCm/rocm-libraries/blob/bee97df517907c771de17189cb867d3c401285ae/projects/rocprim/tuning/tuner/templates/common/base.cpp.jinja2#L56-L59): ```c++ executor.run(); // Return the time as milliseconds per GiB. return (1000 * primbench::GiB) / executor.get_last_bytes_per_second(); ``` This problem was hidden because the autotuning system always picked the existing default config. By passing `--exclude-default-config` to `run_tuning.py` I told it not to use rocPRIM's default config. As expected, this caused a random, slow config to be output, as Kernel Tuner thought every config had an identical speed (`m_last_bytes_per_second`). To prevent downstream autotuning issues, `primbench.hpp` was updated to explicitly forbid calling `state.run()` more than once per state object, matching the existing `set_items` behavior. ## Test Plan Here are the commands I ran while following the instructions in `rocprim/tuning/README.md`: ```sh # Change directory cd projects/rocprim/tuning # Activate virtual environment python -m venv .venv source .venv/bin/activate # Install dependencies pip3 install -i https://test.pypi.org/simple hip-python pip3 install jinja2 kernel-tuner numpy # Run tuning, using Ctrl+\ to stop the process once it finished outputting the first JSON file rm -f output/device_merge_gfx90a_int128_t_cache.json && \ ./run_tuning.py --algo-regex device_merge --seed 42 # Generate configuration ./confgen/generate.py \ --input output/device_merge_gfx90a_int128_t_cache.json \ --output foo --map-gfx gfx90a mi210 ``` To verify the new safeguard, I also intentionally modified `shared/primbench/examples/hip/copy_benchmark.cpp` to call `state.run()` twice in succession. ## Test Result I looked at the terminal output, JSON output, and generated config to confirm the generated config now always matches the fastest specialization. I also confirmed that my test modification in `copy_benchmark.cpp` successfully threw the `"Error: Can't call run() twice"` error and cleanly aborted execution as intended. I also manually checked some specializations of the changed benchmark, to see if the results are the same, and they seemed to be. There is some run-to-run variance, especially with the segmented ones, but that was the same for both versions of the benchmarks. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

assistant-librarian · 2026-09-15T22:53:20Z

TheRock Submodule Bump Activity

Newest first

2026-09-15 — Included in TheRock via ROCm/TheRock#8209.

…totuning (#11760) ## Motivation JIRA ID : EXSWSTRHPC-322 `m_last_bytes_per_second` was always zero, ruining autotuning. Additionally, some rocPRIM benchmarks (such as `projects/rocprim/benchmark/benchmark_device_segmented_reduce.hpp`) mistakenly called `state.run()` multiple times during tuning to test different segment sizes. This caused the bytes/sec returned to Kernel Tuner to be inaccurate and printed the same specialization multiple times to the terminal, which was very confusing. ## Technical Details The `m_last_bytes_per_second` variable is read by [rocprim/tuning/tuner/templates/common/base.cpp.jinja2](https://github.com/ROCm/rocm-libraries/blob/bee97df517907c771de17189cb867d3c401285ae/projects/rocprim/tuning/tuner/templates/common/base.cpp.jinja2#L56-L59): ```c++ executor.run(); // Return the time as milliseconds per GiB. return (1000 * primbench::GiB) / executor.get_last_bytes_per_second(); ``` This problem was hidden because the autotuning system always picked the existing default config. By passing `--exclude-default-config` to `run_tuning.py` I told it not to use rocPRIM's default config. As expected, this caused a random, slow config to be output, as Kernel Tuner thought every config had an identical speed (`m_last_bytes_per_second`). To prevent downstream autotuning issues, `primbench.hpp` was updated to explicitly forbid calling `state.run()` more than once per state object, matching the existing `set_items` behavior. ## Test Plan Here are the commands I ran while following the instructions in `rocprim/tuning/README.md`: ```sh # Change directory cd projects/rocprim/tuning # Activate virtual environment python -m venv .venv source .venv/bin/activate # Install dependencies pip3 install -i https://test.pypi.org/simple hip-python pip3 install jinja2 kernel-tuner numpy # Run tuning, using Ctrl+\ to stop the process once it finished outputting the first JSON file rm -f output/device_merge_gfx90a_int128_t_cache.json && \ ./run_tuning.py --algo-regex device_merge --seed 42 # Generate configuration ./confgen/generate.py \ --input output/device_merge_gfx90a_int128_t_cache.json \ --output foo --map-gfx gfx90a mi210 ``` To verify the new safeguard, I also intentionally modified `shared/primbench/examples/hip/copy_benchmark.cpp` to call `state.run()` twice in succession. ## Test Result I looked at the terminal output, JSON output, and generated config to confirm the generated config now always matches the fastest specialization. I also confirmed that my test modification in `copy_benchmark.cpp` successfully threw the `"Error: Can't call run() twice"` error and cleanly aborted execution as intended. I also manually checked some specializations of the changed benchmark, to see if the results are the same, and they seemed to be. There is some run-to-run variance, especially with the segmented ones, but that was the same for both versions of the benchmarks. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. --------- Co-authored-by: Nick Breed <nick@streamhpc.com> Co-authored-by: Di Nguyen <dinguyennhu@gmail.com>

## Motivation Implement Kernel Tuner for `adjacent` algorithms. JIRA ID: AIPRIMS-236 & EXSWSTRHPC-322 ## Technical Details The rocPRIM config changes are due to running `migrate.py` (this updates the legacy config to be ready for Kernel Tuner) Do not merge this PR until ~~#10790~~, ~~#11109~~ ~~#11760~~ is merged. Recommended way to review this PR is to go to "Commit" and review the files per commit. ## Test Plan Local running of kernel tuner, making sure output matches legacy tuners and that there are no errors. ## Test Result No errors observed for `adjacent_find`, ## Submission Checklist - [ ] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

…totuning (ROCm#11760) ## Motivation JIRA ID : EXSWSTRHPC-322 `m_last_bytes_per_second` was always zero, ruining autotuning. Additionally, some rocPRIM benchmarks (such as `projects/rocprim/benchmark/benchmark_device_segmented_reduce.hpp`) mistakenly called `state.run()` multiple times during tuning to test different segment sizes. This caused the bytes/sec returned to Kernel Tuner to be inaccurate and printed the same specialization multiple times to the terminal, which was very confusing. ## Technical Details The `m_last_bytes_per_second` variable is read by [rocprim/tuning/tuner/templates/common/base.cpp.jinja2](https://github.com/ROCm/rocm-libraries/blob/bee97df517907c771de17189cb867d3c401285ae/projects/rocprim/tuning/tuner/templates/common/base.cpp.jinja2#L56-L59): ```c++ executor.run(); // Return the time as milliseconds per GiB. return (1000 * primbench::GiB) / executor.get_last_bytes_per_second(); ``` This problem was hidden because the autotuning system always picked the existing default config. By passing `--exclude-default-config` to `run_tuning.py` I told it not to use rocPRIM's default config. As expected, this caused a random, slow config to be output, as Kernel Tuner thought every config had an identical speed (`m_last_bytes_per_second`). To prevent downstream autotuning issues, `primbench.hpp` was updated to explicitly forbid calling `state.run()` more than once per state object, matching the existing `set_items` behavior. ## Test Plan Here are the commands I ran while following the instructions in `rocprim/tuning/README.md`: ```sh # Change directory cd projects/rocprim/tuning # Activate virtual environment python -m venv .venv source .venv/bin/activate # Install dependencies pip3 install -i https://test.pypi.org/simple hip-python pip3 install jinja2 kernel-tuner numpy # Run tuning, using Ctrl+\ to stop the process once it finished outputting the first JSON file rm -f output/device_merge_gfx90a_int128_t_cache.json && \ ./run_tuning.py --algo-regex device_merge --seed 42 # Generate configuration ./confgen/generate.py \ --input output/device_merge_gfx90a_int128_t_cache.json \ --output foo --map-gfx gfx90a mi210 ``` To verify the new safeguard, I also intentionally modified `shared/primbench/examples/hip/copy_benchmark.cpp` to call `state.run()` twice in succession. ## Test Result I looked at the terminal output, JSON output, and generated config to confirm the generated config now always matches the fastest specialization. I also confirmed that my test modification in `copy_benchmark.cpp` successfully threw the `"Error: Can't call run() twice"` error and cleanly aborted execution as intended. I also manually checked some specializations of the changed benchmark, to see if the results are the same, and they seemed to be. There is some run-to-run variance, especially with the segmented ones, but that was the same for both versions of the benchmarks. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. --------- Co-authored-by: Nick Breed <nick@streamhpc.com> Co-authored-by: Di Nguyen <dinguyennhu@gmail.com>

Implement Kernel Tuner for `adjacent` algorithms. JIRA ID: AIPRIMS-236 & EXSWSTRHPC-322 The rocPRIM config changes are due to running `migrate.py` (this updates the legacy config to be ready for Kernel Tuner) Do not merge this PR until ~~#10790~~, ~~#11109~~ ~~#11760~~ is merged. Recommended way to review this PR is to go to "Commit" and review the files per commit. Local running of kernel tuner, making sure output matches legacy tuners and that there are no errors. No errors observed for `adjacent_find`, - [ ] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

MyNameIsTrez added the organization: streamhpc contributors from streamhpc label Sep 7, 2026

github-actions Bot added the shared: primbench label Sep 7, 2026

therock-pr-bot Bot added the Not ready to Review label Sep 7, 2026

NB4444 removed the Not ready to Review label Sep 8, 2026

MyNameIsTrez marked this pull request as draft September 8, 2026 11:09

MyNameIsTrez assigned NB4444 Sep 8, 2026

github-actions Bot added the project: rocprim label Sep 8, 2026

NB4444 force-pushed the fix-last-bytes-per-second-being-zero branch from 0222627 to ff8e017 Compare September 8, 2026 13:31

NguyenNhuDi approved these changes Sep 8, 2026

View reviewed changes

NguyenNhuDi mentioned this pull request Sep 8, 2026

feat(rocprim): Implement Kernel Tuner For Adjacent Algorithms #10769

Merged

1 task

NB4444 force-pushed the fix-last-bytes-per-second-being-zero branch 2 times, most recently from 101a044 to 9c3c303 Compare September 9, 2026 09:40

NB4444 marked this pull request as ready for review September 9, 2026 09:41

NB4444 requested a review from a team as a code owner September 9, 2026 09:41

MyNameIsTrez and others added 3 commits September 9, 2026 10:44

fix(rocprim): benchmarks updated to only call run ones for autotuning

5955278

NB4444 force-pushed the fix-last-bytes-per-second-being-zero branch from c3d366f to 5955278 Compare September 9, 2026 10:45

NguyenNhuDi approved these changes Sep 9, 2026

View reviewed changes

NguyenNhuDi added 2 commits September 10, 2026 12:41

Merge branch 'develop' into fix-last-bytes-per-second-being-zero

ff9c282

Merge branch 'develop' into fix-last-bytes-per-second-being-zero

c63e236

NguyenNhuDi merged commit 922a6c8 into develop Sep 14, 2026
121 checks passed

NguyenNhuDi deleted the fix-last-bytes-per-second-being-zero branch September 14, 2026 15:31

Navigation Menu

Repository navigation

fix(primbench): `m_last_bytes_per_second` was always zero, ruining autotuning - #11760

fix(primbench): `m_last_bytes_per_second` was always zero, ruining autotuning#11760
NguyenNhuDi merged 5 commits into
developfrom
fix-last-bytes-per-second-being-zero

MyNameIsTrez commented Sep 7, 2026 •

edited

Loading

Uh oh!

therock-pr-bot Bot commented Sep 7, 2026 •

edited

Loading

Uh oh!

therock-pr-bot Bot commented Sep 7, 2026 •

edited

Loading

Uh oh!

NguyenNhuDi left a comment •

edited

Loading

Uh oh!

NguyenNhuDi left a comment

Uh oh!

Uh oh!

assistant-librarian Bot commented Sep 15, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

MyNameIsTrez commented Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Technical Details

Test Plan

Test Result

Submission Checklist

Uh oh!

therock-pr-bot Bot commented Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ All Checks Passed — Ready for Review

Uh oh!

therock-pr-bot Bot commented Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NguyenNhuDi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NguyenNhuDi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

assistant-librarian Bot commented Sep 15, 2026

TheRock Submodule Bump Activity

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

MyNameIsTrez commented Sep 7, 2026 •

edited

Loading

therock-pr-bot Bot commented Sep 7, 2026 •

edited

Loading

therock-pr-bot Bot commented Sep 7, 2026 •

edited

Loading

NguyenNhuDi left a comment •

edited

Loading