-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make setup async to get rid of setup() #167
base: main
Are you sure you want to change the base?
Conversation
87a034a
to
2426e8e
Compare
9d3fe97
to
cc08b23
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great but is there any potential for slowdowns?
b6108df
to
25c77fe
Compare
Also change bootstrap and context into properties in Communicator
68e42ca
to
2afce03
Compare
This PR changes the
Bootstrap
API to makerecv
calls asynchronous (they return astd::future<void>
) and implements this change inTcpBootstrap
by moving receives to background threads. For each pair of source rank and tag there is a thread that performs the receives in the order they were issued.recv
is marked as[[nodiscard]]
to avoid ignoring the asyncness of the function. However, I didn't see a warning from that in my build and I'm not sure why.The
NonblockingFuture
class is now gone in favor ofstd::future
everywhere.BaseSemaphore
has astd::shared_future
because there are multiple calls toget
in its current form andstd::future
turns invalid after the first call toget
. It might make sense to redesign the semaphores API to return semaphores in astd::future
, so that after initialization the.get()
indirection is avoided.Alternatively, we could make everything
std::shared_future
to make the APIs overall easier to use, although that might feel a bit prescriptive.std::future
can be a bit surprising especially on the Python side where calling.get()
multiple times doesn't feel like it should be an error.As an unrelated change this PR renames
getRank
torank
andgetNRanks
tosize
to conform to C++ and MPI naming.Finally, instead of fixing the existing Python examples I moved the bootstrap example into a Jupyter notebook in the docs/ directory. The other one didn't seem like it's worth keeping anymore since we have the Python tests now.