Closed fknorr closed 7 months ago
Check-perf-impact results: (4c65f1399a47e0eb1340f63004745b17)
:question: No new benchmark data submitted. :question:
Please re-run the microbenchmarks and include the results if your commit could potentially affect performance.
Bikeshedding, from an in-person discussion with @psalz: transfer_id
might not be a good name because it does not uniquely identify a transfer: There can be multiple transfers per transfer_id
on each node (for different subregions) and the same transfer_id + region
can exist multiple times in the cluster if the same data is sent to more than one node.
How about buffer_version
or buffer_version_id
(see source comments)?
Totals | |
---|---|
Change from base Build 7727056751: | 0.02% |
Covered Lines: | 4997 |
Relevant Lines: | 5195 |
How about
buffer_version
orbuffer_version_id
(see source comments)?
I feel like a "buffer version" would have to contain the last writer task id, not the consumer task id. Otherwise two reading tasks that require the same data written by an earlier task would receive two different "versions", even though it's the same data, which seems weird to me.
From in-person discussion: We're leaving the name as-is for the moment to avoid rebase pain in the IDAG branch, and in the hope that documentation will make up for the imperfect name.
This is another back-port from IDAG development.
The
transfer_id
is used to match incoming MPI transfers to await-push commands. Previously this was an integer encoding of "task + chunk id", which together with abuffer_id
, and (optionally) areduction_id
uniquely identifies an await-push on the target node.It turns out that instead of the "magic" chunk id, the task id is sufficient. This PR bundles it with the buffer id and reduction id such that
struct transfer_id
now uniquely identifies the receiving await-push, improving readability of logs / dot graphs and avoiding repetitions of(transfer_id, buffer_id, reduction_id)
in the code.