precompute=True can find maximal subgraphs and consider disjoint components

[arvoelke]

1. Any non-passthrough nodes that compute functions in a chip -> host -> chip loop with precompute=True, raise a BuildError. Instead these subgraphs can be identified and kept off-chip. The maximally-precomputable subgraphs would be precomputed.
2. All disjoint graph components are not considered by the transitive closure algorithm.

[arvoelke]

Discussion point: supporting 1 might just be adding unnecessary complexity, as currently it appears that the simulator doesn't support a hybrid of precompute=True and bidirectional communication with the host. That is, whenever precompute=True, it is assumed that both host models (before and after) can be run in a single run_steps command without needing to send/receive any data between time-steps. It is not clear if this assertion is being validated anywhere.

But a practical example where one might want to do this: a learning example where an input signal is known ahead of time. The learning loop requires interaction on each time-step, but the input can be precomputed independently.

[drasmuss]

Result of internal discussion. Two points: 1) We're worried that it's already kind of confusing for users what parts of a model will be on or off chip, and this might make it worse (by making the on/off logic more complicated). 2) Our goal is to remove the precompute=True option (once the realtime communication speed is improved), so then this wouldn't be an issue. So overall, our plan is just to leave this as-is for now.

[hunse]

A user can always manually specify ensembles to be off chip (by setting the on_chip config parameter for the ensemble to false), which should allow a user to manually achieve the same result if there are subgraphs that they know they want to have off-chip.

[arvoelke]

A user can always manually specify ensembles to be off chip (by setting the on_chip config parameter for the ensemble to false), which should allow a user to manually achieve the same result if there are subgraphs that they know they want to have off-chip.

True but this wouldn't be quite what I wanted because I still want the other parts of the graph to be precomputed in order to simulate as quickly as possible. This may be related to #254 and similar issues with I/O efficiency. If we can get the same performance as precompute=True while running it interactively with the host (as in precompute=False) then I agree this is a non-issue (as are some of the other issues related to the splitter).

Is there an issue for tracking the removal of precompute=True and associated targets / performance benchmarks?