Skip to content

Conversation

@charan-003
Copy link
Contributor

This PR forwards stdexec::bulk and stdexec::bulk_t inside stdexec_forward.hpp.

These were previously commented out. This change makes bulk available through hpx::execution::experimental::bulk, aligning HPX's Sender/Receiver interface with NVIDIA's stdexec implementation.

@charan-003 charan-003 requested a review from hkaiser as a code owner July 18, 2025 17:58
@StellarBot
Copy link

Can one of the admins verify this patch?

@charan-003 charan-003 changed the title updated algorithm_bulk test file Integrate NVIDIA's S/R Bulk implementation into HPX Jul 23, 2025
@hkaiser hkaiser added type: enhancement category: senders/receivers Implementations of the p0443r14 / p2300 + p1897 proposals project: GSoC labels Jul 25, 2025
@charan-003 charan-003 marked this pull request as draft August 2, 2025 06:10
@codacy-production
Copy link

codacy-production bot commented Aug 2, 2025

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
Report missing for c0dab021 94.31%
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (c0dab02) Report Missing Report Missing Report Missing
Head commit (e38f0a4) 209806 175886 83.83%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#6746) 211 199 94.31%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

  1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

@charan-003 charan-003 force-pushed the feature/forward-bulk branch from 49b7122 to ff8a35c Compare August 13, 2025 19:00
Copy link
Contributor

@isidorostsa isidorostsa left a comment

Choose a reason for hiding this comment

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

Excellent work! The tests are checking all the correct things, so if we get them passing we are good to merge :)

isidorostsa
isidorostsa previously approved these changes Sep 16, 2025
@isidorostsa isidorostsa marked this pull request as ready for review September 16, 2025 16:48
isidorostsa
isidorostsa previously approved these changes Sep 17, 2025
Copy link
Contributor

@isidorostsa isidorostsa left a comment

Choose a reason for hiding this comment

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

Really great work!

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's remove those files from this PR as they are being worked on for the same reason by another contributor

Copy link
Contributor

Choose a reason for hiding this comment

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

Changes here are not important

// Continue on
using stdexec::continue_on;
using stdexec::continue_on_t;
// Backward compatibility alias for continues_on
Copy link
Contributor

Choose a reason for hiding this comment

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

No need to have backwards compatibility here, you can remove 134-138


// Additional stdexec concepts and utilities needed for domain customization
using stdexec::__completes_on;
using stdexec::__starts_on;
Copy link
Contributor

Choose a reason for hiding this comment

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

__completes_on, __starts_on, and sender_expr_for should be moved in the stdexec internals namespace

// Concept to match bulk sender types
// Note: We keep bulk_t handling as pragmatic workaround for stdexec template issues
template <typename Sender>
concept any_bulk_sender =
Copy link
Contributor

Choose a reason for hiding this comment

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

should be renamed to bulk_chunked_or_unchunked_sender

constexpr void bulk_scheduler_invoke_helper_chunked(
hpx::util::index_pack<Is...>, F&& f, Start&& start, End&& end, Ts& ts)
{
if constexpr (sizeof...(Is) == 0)
Copy link
Contributor

Choose a reason for hiding this comment

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

We can remove the sizeof...(Is) == 0 test here


auto it = std::next(hpx::util::begin(op_state->shape), i_begin);
for (std::uint32_t i = i_begin; i != i_end; (void) ++it, ++i)
auto it =
Copy link
Contributor

Choose a reason for hiding this comment

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

this should be moved inside the else branch below

{
// Don't spawn tasks if there is no work to be done
auto const size =
// static_cast<std::uint32_t>(op_state->shape);
Copy link
Contributor

Choose a reason for hiding this comment

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

we can remove this commented out part

hpx::is_invocable_v<F, range_value_type,
std::add_lvalue_reference_t<Ts>...>
)>
template <typename... Ts>
Copy link
Contributor

Choose a reason for hiding this comment

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

We should re-add the test as a normal concept (requires) clause

};
} // namespace hpx::execution::experimental::detail

namespace hpx::execution::experimental {
Copy link
Contributor

Choose a reason for hiding this comment

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

Better wrap this in an #if !defined clause instead of removing, so we keep backwards compatibility for now

using stdexec::on_t;

// Continue on
using stdexec::continue_on;
Copy link
Contributor

Choose a reason for hiding this comment

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

This (134, 135) should be removed too, since the proper spelling is continues_on

#include <hpx/coroutines/thread_enums.hpp>
#include <hpx/datastructures/tuple.hpp>
#include <hpx/datastructures/variant.hpp>
#include <hpx/execution/algorithms/bulk.hpp>
Copy link
Contributor

@isidorostsa isidorostsa Oct 2, 2025

Choose a reason for hiding this comment

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

This should be included in the headers when not using STDEXEC, it seems this is what's causing this failing test:

https://app.circleci.com/pipelines/github/STEllAR-GROUP/hpx/18789/workflows/d6fb3490-5f5a-4b18-8cef-730ffef44797/jobs/427793

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 project: GSoC type: enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants