Here are my two cents before diving into the detail code review.
1. At the first glance most implementations, including the Relay passes, were done in Python. It would be better to implement them in C++ for better performance. 2. The term and namespace "subgraph" is improper and confusing. 3. It would be better to break the PR down to 3 smaller PRs (one PR per component) for reviewing. Each component should have its unit tests with hand crafted inputs instead of a single set of unit tests to test all 3 component. Some questions for each component: Compoenent 1: What's the current split logic? From the PR it seems to me that you simply split every op to a subgraph? Ideally we should perform dependency analysis and minimize the number of subgraphs. Component 2: It seems not ideal to let users build each subgraph manually, and from your test case, it seems like users have to make sure the built runtimes are in the correct order? The order should be guaranteed in some artifacts. Meanwhile, it would be better to keep the components independent as well. Specifically, the APIs could be ``` mods, artifacts = split_graph(mod) libs = build(mods, artifacts) runtime = create(libs) runtime.set_input(...) runtime.run() ``` One important point is **the build API does not have a strong dependency to split_graph**. Suppose a user prepares a list of modules as well as the artifacts by herself, the `build` API should also work. That's why I feel the first and second/third components should be in separate PRs. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-compute-graph-pipeline-with-new-subgraph-executor/9839/3) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/b65d92eb12bab7f5f3a301f4e0cca385ef240c1b434dd58316f21791189bf665).
