Feature/task bench support#6876
Conversation
|
Can one of the admins verify this patch? |
8b98668 to
76253cb
Compare
hkaiser
left a comment
There was a problem hiding this comment.
@guptapratykshh Did you implement the HPX version of task_bench?
|
Yes, i am working on HPX implementation, utilizing hpx::execution::experimental::fork_join_executor to efficiently handle intra node parallelism for task graph |
Thanks! The only thing I'm unsure of is whether we really should add the whole task_bench code base to our repository. Wouldn't it be better to upstream your changes to them? |
|
@hkaiser, you are right, i have upstreamed the implementation to task bench - StanfordLegion/task-bench#101 |
|
@guptapratykshh I'm going to close this without merging. Please re-open if you feel that we will pursue this PR any further. |
|
@hkaiser now we should re-open this PR as this StanfordLegion/task-bench#101 is merged as well as the race condition(StanfordLegion/task-bench#94 (comment)) has also been fixed in that PR |
|
@guptapratykshh when pushing to this PR, please remove the task-bench code by force-pushing to remove it completely from the git history. |
Up to standards ✅🟢 Issues
|
e014ade to
464f5de
Compare
There was a problem hiding this comment.
Pull request overview
Adds TaskBench benchmark support to the HPX examples by integrating an external TaskBench checkout and building HPX TaskBench driver executables as part of the examples build.
Changes:
- Introduces
examples/task_benchCMake logic that fetches TaskBench and builds the core library + HPX driver executables. - Adds
task_benchto the top-level examples subdirectory list so it is built when examples are enabled.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
| examples/task_bench/CMakeLists.txt | Fetches upstream TaskBench and defines build targets for TaskBench core + HPX drivers. |
| examples/CMakeLists.txt | Registers task_bench as an examples subdirectory. |
20c5f35 to
302334a
Compare
Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
da55791 to
beb2d61
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
libs/core/async_cuda/include/hpx/async_cuda/cuda_executor.hpp (1)
142-165: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value
F/post_impl/async_implare effectively restricted to raw function pointers, not arbitrary callables.The public
post/async_executetemplates are generic overF&&, butpost_impl/async_implonly acceptR (*)(Params...)function pointers (needed fordetail::dispatch_helper). Passing a lambda orstd::functionwill fail template deduction with a generic "no matching function" error rather than a clear diagnostic. This is pre-existing behavior carried over from the previous naming, not a regression, but worth a doc note if callers outside this refactor start passing non-pointer callables.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@libs/core/async_cuda/include/hpx/async_cuda/cuda_executor.hpp` around lines 142 - 165, The generic public templates `post` and `async_execute` currently forward to `post_impl` and `async_impl`, which only accept raw function pointers via `detail::dispatch_helper`, so non-pointer callables like lambdas or `std::function` will fail with an unclear deduction error. Add an explicit note or constraint near `post_impl`/`async_impl` (and the public wrappers if needed) that these paths only support plain CUDA function pointers, and prefer a clear compile-time diagnostic or documentation to steer callers toward the supported signature.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@libs/core/async_cuda/include/hpx/async_cuda/cuda_executor.hpp`:
- Around line 142-165: The generic public templates `post` and `async_execute`
currently forward to `post_impl` and `async_impl`, which only accept raw
function pointers via `detail::dispatch_helper`, so non-pointer callables like
lambdas or `std::function` will fail with an unclear deduction error. Add an
explicit note or constraint near `post_impl`/`async_impl` (and the public
wrappers if needed) that these paths only support plain CUDA function pointers,
and prefer a clear compile-time diagnostic or documentation to steer callers
toward the supported signature.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 55ff7c32-765c-444b-8e72-bceaf7b618e3
📒 Files selected for processing (7)
CMakeLists.txtexamples/CMakeLists.txtexamples/task_bench/CMakeLists.txtlibs/core/async_cuda/include/hpx/async_cuda/cublas_executor.hpplibs/core/async_cuda/include/hpx/async_cuda/cuda_executor.hpplibs/core/async_cuda/include/hpx/async_cuda/transform_stream.hpplibs/core/async_cuda/tests/unit/transform_stream.cu
✅ Files skipped from review due to trivial changes (1)
- examples/CMakeLists.txt
🚧 Files skipped from review as they are similar to previous changes (2)
- CMakeLists.txt
- examples/task_bench/CMakeLists.txt
|
@hkaiser I ran a configure sanity check for the example. After enabling HPX_WITH_EXAMPLES_TASKBENCH and allowing HPX to fetch its missing dependencies, examples/task_bench configured cleanly, and hpx_fork_join built successfully against local TaskBench checkout |
|
Should we add building and running this example to one of the CIs? |
|
yes,i think build coverage in CI would be a good idea. for the default matrix,i did start with taskbench build job plus a small hpx_fork_join smoke test. i will keep distributed hpx_distributed run in a separate or nightly CI job |
I think you could add it to one of the existing github CIs. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/linux_debug_fetch_boost.yml (1)
26-37: 🧹 Nitpick | 🔵 TrivialNote: additional network dependency on external task-bench fetch.
This job now fetches Boost, Asio, and (via
HPX_WITH_EXAMPLES_TASKBENCH=ON) upstreamStanfordLegion/task-benchsources during configure, all over the network in CI. Consider whether the upstreamFetchContentcall pins a specific tag/commit (reviewed in another layer) and whether retry/caching is warranted here to reduce CI flakiness from an additional external fetch.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/linux_debug_fetch_boost.yml around lines 26 - 37, Review the CMake configuration enabled by HPX_WITH_EXAMPLES_TASKBENCH=ON and pin the task-bench FetchContent dependency to a reviewed tag or commit rather than an unversioned upstream source. Add appropriate retry or caching support for this additional network fetch while preserving the existing task-bench example build.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/linux_debug_fetch_boost.yml:
- Around line 26-37: Review the CMake configuration enabled by
HPX_WITH_EXAMPLES_TASKBENCH=ON and pin the task-bench FetchContent dependency to
a reviewed tag or commit rather than an unversioned upstream source. Add
appropriate retry or caching support for this additional network fetch while
preserving the existing task-bench example build.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 0bb99ee1-76bf-4ef3-b225-d1143a80fc39
📒 Files selected for processing (2)
.github/workflows/linux_debug_fetch_boost.ymlexamples/task_bench/CMakeLists.txt
🚧 Files skipped from review as they are similar to previous changes (1)
- examples/task_bench/CMakeLists.txt
3ef23ff to
c447060
Compare
Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
c447060 to
3f66cb8
Compare
767e3cf to
29b9176
Compare
Signed-off-by: guptapratykshh <pratykshgupta9999@gmail.com>
29b9176 to
3ad67cd
Compare
hkaiser
left a comment
There was a problem hiding this comment.
LGTM, thanks!
You may want to consider to upstream changes that fix the deprecation warnings on their end.
Fixes #4274
Proposed Changes
examples/task_bench/that builds the HPX task-bench drivers from the upstream task-bench repository (StanfordLegion/task-bench) via CMakeFetchContent. No task-bench source files are vendored in this PR — everything is fetched from upstream.hpx_fork_join— fork-join executor for intra-node parallelism (no MPI required)hpx_distributed— default parallel executor + MPI for inter-node parallelism (built only when MPI is found)HPX_WITH_EXAMPLES_TASKBENCH(default OFF) that gates the example. Users must explicitly enable it (-DHPX_WITH_EXAMPLES_TASKBENCH=ON) to build task-bench alongside HPX.core/library) and whenHPX_WITH_DISTRIBUTED_RUNTIME=OFF.Any background context you want to provide?
Checklist
Not all points below apply to all pull requests.