Skip to content

Simplify shuffle completion tracking#914

Open
wence- wants to merge 5 commits intorapidsai:mainfrom
wence-:wence/fea/shuffle-single-finish
Open

Simplify shuffle completion tracking#914
wence- wants to merge 5 commits intorapidsai:mainfrom
wence-:wence/fea/shuffle-single-finish

Conversation

@wence-
Copy link
Contributor

@wence- wence- commented Mar 12, 2026

Rather than tracking completion per rank stratified by partition, switch to only tracking completion by rank. This is more preparatory work towards making it possible to reuse op-ids in shuffles once they are locally complete.

There are two changes here:

  1. API facing: changing insert_finished to no longer accept finished partitions
  2. Internal: changing the completion tracking mechanism.

I can split these apart if that's preferred.

@wence- wence- requested review from a team as code owners March 12, 2026 17:59
@wence- wence- added breaking Introduces a breaking change improvement Improves an existing functionality labels Mar 12, 2026
wence- added 2 commits March 12, 2026 18:03
We're going to track completion only by rank, not additionally stratified
by partition, so there's no need to have insert_finished take a vector
finished partitions.
This simplifies the tracking data structures and will make it easier to
implement shuffles that don't cross-talk.
@wence- wence- force-pushed the wence/fea/shuffle-single-finish branch from de6ef8c to eb10693 Compare March 12, 2026 18:03
Copy link
Member

@madsbk madsbk left a comment

Choose a reason for hiding this comment

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

First pass, this is great. I really like the simplification.

But I think we should mention somewhere (maybe in the wait_any() docstring) that we previously supported finishing on a per-partition basis. In theory this could enable more concurrency, but in practice it didn’t really matter because the user program logic needs all partitions to be received before it can continue.

It might also be worth adding a reference to this PR there.

@wence-
Copy link
Contributor Author

wence- commented Mar 13, 2026

First pass, this is great. I really like the simplification.

But I think we should mention somewhere (maybe in the wait_any() docstring) that we previously supported finishing on a per-partition basis. In theory this could enable more concurrency, but in practice it didn’t really matter because the user program logic needs all partitions to be received before it can continue.

It might also be worth adding a reference to this PR there.

Done.

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

Labels

breaking Introduces a breaking change improvement Improves an existing functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants