Closed fknorr closed 6 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.
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
src/recorders.cc | 24 | 25 | 96.0% | ||
<!-- | Total: | 205 | 206 | 99.51% | --> |
Totals | |
---|---|
Change from base Build 7970610878: | 0.1% |
Covered Lines: | 5046 |
Relevant Lines: | 5239 |
Check-perf-impact results: (f7ef1830fe7f830eee417b0b5a37c2ef)
:question: No new benchmark data submitted. :question:
Please re-run the microbenchmarks and include the results if your commit could potentially affect performance.
I've gone ahead and renamed every buffer_state
variable to buffer
in the DGGen for consistency.
Check-perf-impact results: (19e9c0e63e2eff8d602cc7a81b622c19)
:heavy_check_mark: No significant performance change in the microbenchmark set. You are good to go!
Relative execution time per category: (mean of relative medians)
This is a back-port from IDAG development and a second attempt at #216.
task_manager
anddistributed_graph_generator
already maintain state for each buffer (add_buffer()
) and host object (implicit on creation) , but keep that state around indefinitely even after the buffer or host object in question is destroyed. Also, neither graph generator has access to buffer debug names and thus can't include that information in error reports (such as uninitialized-read detection, there is a TODO in the code about this).This PR adds explicit member functions for tracking the creation and destruction of buffers (
create_buffer
,destroy_buffer
) and host objects (create_host_object
,destroy_host_object
) totask_manager
,distributed_graph_generator
,scheduler
; and now by necessity,runtime
, which receives these requests directly instead of indirectly throughbuffer_manager::buffer_lifetime_callback
.It also removes the
recorder
->buffer_manager
dependency by replicating the buffer name (like all other metadata) in both graph generators. This foreshadows the eventual removal ofbuffer_manager
post-IDAG.I purposefully changed the recording API such that its user is responsible for constructing records and the recorder simply aggregates them. This is now possible because the recorders do not need to know about
task_manager
andbuffer_manager
anymore, and will allow us, in the future, to add debug info to records that is not present in the "real" DAG (see the upcoming instruction graph generator for how this might look).