sPyNNaker
sPyNNaker copied to clipboard
SpiNNakerManchester
better delay_support_adder on second pass
To avoid creating more DelayExtensionVertex than need the _DelaySupportAdder keeps a map of app_outgoing_edge_partition to Vertex.
If the same vertex would be followed by a delay more than once the value from that map is used.
-- The issue is what happens the second time DelaySupportAdder is run.
The current solution is to throw away the ApplicationGraph and clone a new one. But as far as I can see in reduce overheads the DelaySupportAdder is the last requirement for this clone.
Options considered are:
-
Keep the app_to_delay_map
-
Add data to DelayExtensionVertex so that the map can be repopulated on a second pass
-
Go through the Graph and remove all Delay stuff before reading
There may also be stuff needed for finding Edges but a similar approach can be used there.
A better overall solution would be to remove adding of delay extensions based on an algorithm, and instead add delay extensions to the splitters. A splitter can decide whether a delay extension is needed internally, though this probably should be a common function that splitters can use since it is likely based on the splitters on target edges.
yes doing it in the splitter and only adding to Machine graph is the nicest but probably hardest solution
It probably isn't that hard; the code to decide whether to do it or not is already there, it just needs to move into the splitter rather than be outside it, and to add machine vertices instead of application vertices. That said, it might be easier once reduce_overhead is in place, as that puts less constraints on delays and how the data gets back to them.
Actually, if this is to happen in reduce_overhead anyway, I can probably push in a fix without too much effort...
The biggest issue with move adding delays to the splitter is that then the DelayExtensionMachineVertex has no DelayExtensionVertex app vertex so the places where the Machine Vertex depends on the App Vertex have to be changed.
The problem is harder than insert_extra_monitor_vertices_to_graphs and insert_chip_power_monitors_to_graphs
In both of those case there are only Vertices which are placed based on the Machine so they can become just System Placements . Placements are cleared after a hard reset so that automatically clears the System Vertices.
Delays also have Edge/Partitions and these need routing_info_allocation and routing. So if the Delays are not to be added to the Application Graph where are they stored