feat(bench): add stdexec benchmark mirroring bench/beman/#288
Conversation
Parallel benchmark under bench/stdexec/ that exercises the same I/O
read-stream workload as bench/beman/ but uses NVIDIA stdexec instead
of beman::execution. Gated by a new CMake option
BOOST_CAPY_BUILD_STDEXEC_EXAMPLES, independent from the existing
BOOST_CAPY_BUILD_P2300_EXAMPLES.
Three tables x four rows x two columns:
Table 1: sender/receiver pipeline (exec::repeat_until)
Table 2: capy::task (capy::thread_pool)
Table 3: exec::task (exec::static_thread_pool)
Rows: Native / Abstract / Type-erased / Synchronous
Idiomatic stdexec throughout: exec::static_thread_pool,
exec::task<void>, exec::any_sender<any_receiver<completion_signatures<>>>
(post PR #2040), exec::repeat_until, and write_env(prop(
exec::get_frame_allocator, alloc)) at type-erased pipeline roots so
op-state storage routes through the counting/recycling resource.
Bridges between stdexec and capy executor model:
- capy::as_sender(IoAwaitable) -> stdexec sender
- capy::await_sender(stdexec snd) -> IoAwaitable
- sender_as_capy_executor + pool_scheduler + static_pool_context
adapt exec::static_thread_pool to capy's Executor concept
Table 1 cells use exec::static_thread_pool(2) to work around
exec::repeat_until's single-worker deadlock (it synchronously
emplaces iteration N+1 inside iteration N's set_value cascade, so
a single worker can't drain the queue it just posted to). Tables 2
and 3 stay at pool(1) because co_await suspension releases the
worker between iterations. The header comment in main.cpp documents
this trade-off.
Two stdexec gaps documented in the source comments:
- exec::any_sender value-storage on construction can't route
through get_frame_allocator (env not visible at construction time)
- exec::task has no allocator hook for coroutine frames
|
An automated preview of the documentation is available at https://288.capy.prtest3.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-05-21 15:51:48 UTC |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #288 +/- ##
========================================
Coverage 92.27% 92.27%
========================================
Files 164 164
Lines 8862 8862
========================================
Hits 8177 8177
Misses 685 685
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
GCOVR code coverage report https://288.capy.prtest3.cppalliance.org/gcovr/index.html Build time: 2026-05-21 16:09:27 UTC |
2 participants
Parallel benchmark under bench/stdexec/ that exercises the same I/O read-stream workload as bench/beman/ but uses NVIDIA stdexec instead of beman::execution. Gated by a new CMake option
BOOST_CAPY_BUILD_STDEXEC_EXAMPLES, independent from the existing BOOST_CAPY_BUILD_P2300_EXAMPLES.
Three tables x four rows x two columns:
Table 1: sender/receiver pipeline (exec::repeat_until)
Table 2: capy::task (capy::thread_pool)
Table 3: exec::task (exec::static_thread_pool)
Rows: Native / Abstract / Type-erased / Synchronous
Idiomatic stdexec throughout: exec::static_thread_pool, exec::task, exec::any_sender<any_receiver<completion_signatures<>>> (post PR #2040), exec::repeat_until, and write_env(prop( exec::get_frame_allocator, alloc)) at type-erased pipeline roots so op-state storage routes through the counting/recycling resource.
Bridges between stdexec and capy executor model:
adapt exec::static_thread_pool to capy's Executor concept
Table 1 cells use exec::static_thread_pool(2) to work around exec::repeat_until's single-worker deadlock (it synchronously emplaces iteration N+1 inside iteration N's set_value cascade, so a single worker can't drain the queue it just posted to). Tables 2 and 3 stay at pool(1) because co_await suspension releases the worker between iterations. The header comment in main.cpp documents this trade-off.
Two stdexec gaps documented in the source comments: