Skip to content

Implement P2300 bulk adapter for HPX executors#7240

Open
shivansh023023 wants to merge 11 commits into
TheHPXProject:masterfrom
shivansh023023:feat/p2300-bulk-integration
Open

Implement P2300 bulk adapter for HPX executors#7240
shivansh023023 wants to merge 11 commits into
TheHPXProject:masterfrom
shivansh023023:feat/p2300-bulk-integration

Conversation

@shivansh023023
Copy link
Copy Markdown
Contributor

P2300 bulk Integration for HPX Executors

Description

This PR implements the P2300 bulk sender adapter specifically for HPX's legacy executors, including the parallel_executor and sequenced_executor. By bridging the hpx::execution::experimental::bulk algorithm with HPX's internal bulk_sync_execute mechanism, this change ensures that data-parallel workloads are properly load-balanced and optimized using HPX's high-performance partitioners.

Key Technical Improvements:

  • Algorithmic Bridging: Successfully mapped the C++23 bulk sender to the underlying HPX execution engine for native parallel performance.
  • Robust tag_invoke Overloads: Implemented a full suite of connect_t overloads (supporting &&, &, and const&) to ensure compatibility with consumer algorithms like sync_wait.
  • Reference Stability: Utilized std::decay_t within the bulk_receiver to prevent reference collapsing and ensure the safety of deferred functional object execution.
  • Architectural Integrity: Resolved a potential circular dependency by situating the implementation within the executors module rather than the core execution module.

Proposed Changes

  • [New] libs/core/executors/include/hpx/executors/executor_scheduler_bulk.hpp: Implements executor_bulk_sender and executor_bulk_receiver.
  • [Modified] libs/core/executors/include/hpx/executors/executor_scheduler.hpp: Exposes get_completion_scheduler_t for ADL discovery.
  • [Modified] libs/core/executors/include/hpx/executors/parallel_executor.hpp & sequenced_executor.hpp: Integrated the new bulk headers.
  • [New Test] libs/core/executors/tests/unit/executor_algorithm_bulk.cpp: Comprehensive validation for sequential and parallel policies.

Background context

This work is part of the ongoing effort to modernize HPX's execution model to align with the C++23 Sender/Receiver (P2300) standard. Implementing bulk is a "Big Impact" milestone because it allows modern asynchronous pipelines to tap into the mature, multi-threaded performance of the HPX runtime.

Checklist

  • I have added a new feature and have added tests to go along with it.
  • I have verified the implementation with a local build of the executor_algorithm_bulk_test target.
  • I have ensured all includes are strictly alphabetically sorted to comply with the HPX inspect tool.

@shivansh023023 shivansh023023 requested a review from hkaiser as a code owner May 2, 2026 17:39
@StellarBot
Copy link
Copy Markdown
Collaborator

Can one of the admins verify this patch?

@codacy-production
Copy link
Copy Markdown

codacy-production Bot commented May 2, 2026

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@shivansh023023 shivansh023023 force-pushed the feat/p2300-bulk-integration branch from 5cdcfbd to 7b3fc5f Compare May 2, 2026 17:50
@hkaiser
Copy link
Copy Markdown
Contributor

hkaiser commented May 3, 2026

@shivansh023023 Just FYI, before you invest more time into our old sender/receiver implementation: #7123 will soon remove almost all of our code related to this. Please focus your efforts on whatever stays after this has been merged.

@hkaiser hkaiser added category: senders/receivers Implementations of the p0443r14 / p2300 + p1897 proposals type: enhancement type: compatibility issue labels May 3, 2026
@shivansh023023
Copy link
Copy Markdown
Contributor Author

@hkaiser

Thank you for the heads-up regarding #7123. I appreciate the guidance to avoid spending effort on code that will soon be deprecated.

I will pause my work on the current P2300 bulk adapter and follow the progress of #7123 closely. Once that is merged, I’ll re-evaluate how to implement the bulk functionality within the new framework.

In the meantime, I’ll focus on finishing the review items for PR #7070 (local convenience header) and cleaning up any remaining issues on my other active PRs that are unaffected by the sender/receiver removal.

Comment thread libs/core/executors/include/hpx/executors/executor_scheduler_bulk.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/parallel_executor.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/parallel_executor.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/sequenced_executor.hpp Outdated
@shivansh023023
Copy link
Copy Markdown
Contributor Author

Hi @hkaiser

Thank you for the feedback. I have refactored the PR to align with the latest stdexec changes:

Purged Legacy Code: Removed all !defined(HPX_HAVE_STDEXEC) blocks from executor_scheduler_bulk.hpp.

Header Optimization: Removed the inclusions of executor_scheduler.hpp and executor_scheduler_bulk.hpp from the parallel_executor and sequenced_executor headers.

Forward Declarations: Implemented forward declarations for the returned scheduler types in the executor headers to prevent bloat.

Fixed Includes: Removed the reference to the deprecated get_scheduler.hpp header.

The headers are now much cleaner. Let me know if there are any other areas you'd like me to slim down!

Comment thread libs/core/executors/include/hpx/executors/parallel_executor.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/parallel_executor.hpp
Comment thread libs/core/executors/include/hpx/executors/parallel_executor.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/parallel_executor.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/sequenced_executor.hpp Outdated
Comment thread libs/core/executors/tests/unit/executor_algorithm_bulk.cpp Outdated
Comment thread libs/core/executors/tests/unit/executor_algorithm_bulk.cpp Outdated
Copy link
Copy Markdown
Contributor

@charan-003 charan-003 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice work!!!

Copy link
Copy Markdown
Contributor

@charan-003 charan-003 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice work!!!

Comment thread libs/core/executors/include/hpx/executors/executor_scheduler.hpp
Comment thread libs/core/executors/include/hpx/executors/executor_scheduler.hpp Outdated
shivansh023023 pushed a commit to shivansh023023/hpx that referenced this pull request May 7, 2026
…nder/receiver concepts, NVCC guard, dedup get_scheduler, fix post() UB, use get_scheduler in tests
@shivansh023023 shivansh023023 force-pushed the feat/p2300-bulk-integration branch from bbfc7db to 1f4aeee Compare May 7, 2026 06:35
@shivansh023023
Copy link
Copy Markdown
Contributor Author

Hi @hkaiser

Thank you for the architectural guidance! I have implemented your suggestions to clean up the header dependencies and tag_invoke logic:

Forwarding Header: I created executor_scheduler_fwd.hpp and moved the declarations there, which allowed me to strip the redundant forward declarations from the individual executor headers.

Tag-Invoke Overloads: I removed the default template arguments and duplicate overloads in parallel_executor and sequenced_executor, replacing them with the concrete friend functions you suggested.

NVCC Fix: I ensured the NVCC/CUDACC guards for the destructors were correctly restored.

Standard Test Patterns: I updated the unit tests to use the standard ex::get_scheduler(exec) call instead of manual constructor calls.

The structure feels much more consistent with the rest of the HPX core modules now. Thanks!

@shivansh023023
Copy link
Copy Markdown
Contributor Author

Hi @charan-003

Thanks for the catch on the stdexec compliance and the safety issues! I’ve updated the implementation as follows:

Sender/Receiver Concepts: I added sender_concept to executor_sender and receiver_concept to executor_bulk_receiver. These are now correctly picked up by the stdexec concept checks.

UB Fix in post: I refactored the lambda capture in executor_operation_state::start(). It now captures the state by reference and only moves the receiver inside the task body. This ensures that if hpx::parallel::execution::post throws, the receiver is still valid for the set_error call in the catch block.

I really appreciate the eye for detail on that potential move-before-post UB,definitely a safer implementation now!

Comment thread libs/core/executors/include/hpx/executors/executor_scheduler.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/executor_scheduler_bulk.hpp Outdated
Comment thread libs/core/executors/include/hpx/executors/parallel_executor.hpp Outdated
@shivansh023023 shivansh023023 force-pushed the feat/p2300-bulk-integration branch from d0b7f07 to 7ab5571 Compare May 8, 2026 07:39
@shivansh023023
Copy link
Copy Markdown
Contributor Author

@hkaiser
I have just pushed the latest updates for PR #7240, and I’m happy to report that all CI checks are passing! I’ve implemented your latest suggestions to fully modernize the implementation:

C++20 Concepts: I’ve replaced the legacy std::enable_if_t in the executor_scheduler constructor with a clean C++20 requires clause and included the header.

Purged Redundant Guards: Removed the #if defined(HPX_HAVE_STDEXEC) guards in executor_scheduler_bulk.hpp, as we now rely strictly on the modern Sender/Receiver path.

Header Optimization: I have completely removed the implementation headers (executor_scheduler.hpp and executor_scheduler_bulk.hpp) from parallel_executor.hpp and sequenced_executor.hpp. These files now rely solely on the lightweight executor_scheduler_fwd.hpp header, significantly reducing the include bloat for the core executors.

The code is now much cleaner and follows the forwarding pattern we discussed. It should be ready for a final review!

@hkaiser
Copy link
Copy Markdown
Contributor

hkaiser commented May 8, 2026

@shivansh023023 Thanks for the updates. I'd like to wait for #7257 to be finalized before merging anything else related to s&r. Please be patient as this may take a moment.

@shivansh023023
Copy link
Copy Markdown
Contributor Author

@shivansh023023 Thanks for the updates. I'd like to wait for #7257 to be finalized before merging anything else related to s&r. Please be patient as this may take a moment.

Sure sir

@shivansh023023
Copy link
Copy Markdown
Contributor Author

Hey @hkaiser , all the CI checks are passing and I've implemented all your feedback
from the last review. Can you review it again and tell me if it needs any improvements or can it be merged

@hkaiser
Copy link
Copy Markdown
Contributor

hkaiser commented May 16, 2026

Hey @hkaiser , all the CI checks are passing and I've implemented all your feedback from the last review. Can you review it again and tell me if it needs any improvements or can it be merged

Could you please look into the conflicts? Those will have to be resolved before moving on.

@charan-003 Could you please have a look here to see how that interplays with #6655?

@charan-003
Copy link
Copy Markdown
Contributor

@charan-003 Could you please have a look here to see how that interplays with #6655?

executor_scheduler adapter for legacy executors with bulk via bulk_sync_execute. My #6655 adds the P2079R7 parallel_scheduler with policy-aware bulk in thread_pool_scheduler_bulk. Different scheduler types, no architectural conflict.

This PR helps older HPX executors (parallel_executor, sequenced_executor) use P2300 bulk in sender pipelines. My #6655 covers the new scheduler side. Same user goal (bulk support), different backend paths by scheduler

I just need to update my PR so it follows the same style(P2300)

@codacy-production
Copy link
Copy Markdown

codacy-production Bot commented May 17, 2026

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@shivansh023023 shivansh023023 force-pushed the feat/p2300-bulk-integration branch 2 times, most recently from 01f7224 to 371a9ee Compare May 17, 2026 10:09
shivansh023023 pushed a commit to shivansh023023/hpx that referenced this pull request May 17, 2026
…nder/receiver concepts, NVCC guard, dedup get_scheduler, fix post() UB, use get_scheduler in tests

Signed-off-by: Shivansh <singhshivansh023@gmail.com>
@shivansh023023 shivansh023023 force-pushed the feat/p2300-bulk-integration branch from 371a9ee to 6a61c4e Compare May 17, 2026 14:11
Hackathon User and others added 8 commits May 17, 2026 19:44
- Integrated hpx::execution::experimental::bulk with internal bulk_sync_execute
- Implemented robust tag_invoke(connect_t) with full const-correctness
- Fixed receiver reference collapsing using std::decay_t
- Added executor_algorithm_bulk unit tests for parallel and sequenced execution

Signed-off-by: Shivansh <singhshivansh023@gmail.com>
…nder/receiver concepts, NVCC guard, dedup get_scheduler, fix post() UB, use get_scheduler in tests

Signed-off-by: Shivansh <singhshivansh023@gmail.com>
Signed-off-by: Shivansh <singhshivansh023@gmail.com>
…rm_completion_signatures

Signed-off-by: Shivansh <singhshivansh023@gmail.com>
…cutor includes

Signed-off-by: Shivansh <singhshivansh023@gmail.com>
The requires clause in both the sequential and parallel tag_fallback_invoke
overloads of hpx::unique_copy_t incorrectly constrained the predicate
against the output iterator's value type:

  is_invocable_v<Pred, iter_value_t<InIter>, iter_value_t<OutIter>>   // wrong
  is_invocable_v<Pred, iter_value_t<FwdIter1>, iter_value_t<FwdIter2>> // wrong

unique_copy compares consecutive elements of the *input* range only
([alg.unique]). The output iterator is write-only; its value type is
irrelevant to the predicate. The correct form is:

  is_invocable_v<Pred, iter_value_t<InIter>, iter_value_t<InIter>>

This is already the form used in hpx::ranges::unique_copy (via
is_indirect_callable_v with projected<Proj, InIter> for both arguments),
making this fix also restore consistency between the two API surfaces.

Add test_unique_copy_constraint<IteratorTag>() to unique_copy_tests.hpp
covering all execution policies (seq, par, par_unseq, seq(task),
par(task)) with a strongly-typed binary predicate, plus seven edge cases:
empty range, single element, all-identical, no-duplicates, and two-element
identical/distinct variants. All verified against std::unique_copy.

Signed-off-by: Aneek22112007 <das.aneek007@gmail.com>
Signed-off-by: Shivansh <singhshivansh023@gmail.com>
The existing godbolt-minimal preset (added in TheHPXProject#7063) is missing several
flags required for a correct Compiler Explorer integration:

1. Add HPX_WITH_DISTRIBUTED_RUNTIME=OFF: HPX_WITH_NETWORKING=OFF alone
   does not disable the distributed runtime -- AGAS, actions, and the
   parcelset infrastructure are still compiled, wasting ~30% build time
   and producing libraries that CE will never use.

2. Add HPX_WITH_CXX_STANDARD=20: pins the C++ standard explicitly so
   builds are deterministic across GCC/Clang versions. Uses HPX's own
   cache variable (not CMAKE_CXX_STANDARD, which HPX rejects unless
   HPX_USE_CMAKE_CXX_STANDARD is also set).

3. Add HPX_WITH_TOOLS=OFF: CE only needs libraries and headers; building
   HPX tools adds unnecessary build time.

4. Improve description: document the produced static libraries
   (libhpx_wrap.a, libhpx_init.a, libhpx.a, libhpx_core.a) and the
   required -Wl,-wrap=main linker flag for non-CMake consumers.

5. Reorder cache variables to group related flags logically:
   standard -> linking -> runtime -> dependencies -> build targets.

Signed-off-by: Shivansh <singhshivansh023@gmail.com>
Signed-off-by: Shivansh <singhshivansh023@gmail.com>
@shivansh023023 shivansh023023 force-pushed the feat/p2300-bulk-integration branch from 6a61c4e to 993005b Compare May 17, 2026 14:14
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are unrelated to this PR. Please remove.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, these changes are unrelated.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated changes, please remove.

Comment thread CMakePresets.json
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are unrelated as well.

Comment thread libs/core/executors/CMakeLists.txt Outdated
Comment thread libs/core/executors/include/hpx/executors/executor_scheduler.hpp Outdated
…tions

Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
Copy link
Copy Markdown
Contributor

@hkaiser hkaiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR still has a couple of unrelated changes, please remove those. Also, I'd like for this to be compatible with #6655, let's wait for that to be merged to revisit things here.

… modifiers

Signed-off-by: Shivansh Singh <singhshivansh023@gmail.com>
@shivansh023023
Copy link
Copy Markdown
Contributor Author

shivansh023023 commented May 18, 2026

This PR still has a couple of unrelated changes, please remove those. Also, I'd like for this to be compatible with #6655, let's wait for that to be merged to revisit things here.

Ok sir , I will fix my other PR's till then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category: senders/receivers Implementations of the p0443r14 / p2300 + p1897 proposals type: compatibility issue type: enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants