Skip to content
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

Unused bindings remain in DAG when concatenating #559

Open
majosm opened this issue Nov 8, 2024 · 0 comments
Open

Unused bindings remain in DAG when concatenating #559

majosm opened this issue Nov 8, 2024 · 0 comments

Comments

@majosm
Copy link
Collaborator

majosm commented Nov 8, 2024

With the current concatenation implementation (#477), a situation can arise where call bindings that are not needed by the computation are retained in the DAG.

From the perspective of a given function parameter, if the result of the computation depends on the bindings for that parameter uniformly for all calls (i.e., the computation either uses the binding from every call or none of them), then everything works as expected: either all of the bindings remain in the DAG or they are all dropped. However, if the computation depends on bindings for some of the calls and not others, then all of the bindings still remain in the DAG. This is not ideal, as it can lead to unnecessary computation (+ communication, in the case of MIRGE-Com).

Some sketches of this can be found here. The DAGs represent a computation in which the first output of an outlined function depends on the first function parameter and the second output depends on the second parameter. The second output may or may not be used in the computation (and thus the second parameter bindings may not be needed). Case 1 is the situation where none of the second call results are used, and everything works as desired (the "recv"s are dropped). Case 2 shows that when the second output is used in one of the calls, the second parameter bindings are retained from all of the calls instead of just the one that is needed.

Potentially this can be fixed by modifying the function body concatenation processing to only include the needed calls. In other words, when applying concatenation to a given function output, it could look at which of the calls' corresponding outputs are actually needed by the computation and only concatenate those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant