> @Mousius In this case, @YuchenJin 's reply clearly articulated that there is > a close co-design of these factors, and changing to adopt dynamic alone would > imply a one-step jump to relax -- which is not incremental. The data > structure change would come with a set of supporting infra and co-design of > things including shape inference, and other things.
Co-design doesn't mean we have to land everything at once, it's often easier to prototype several features together and then break them down when we get to delivery - I believe that is most incremental and understandable rather than landing large changes with several dimensions at once. I'm also unsure how it's a one-step jump to Relax as @YuchenJin has demonstrated that the functionality of Relax is split into several different pieces. I understand that in order to land the entire proposition of Relax it may take several pieces landing, but that's natural for a large change such as this? > Of course, if we do not maintain both behavior and allow an incremental > transition. Then it is equivalent to a relay=>relax bridge that would allow > part of the pipeline to go through in a more incremental fashion. This > approach is consistent with what is being proposed in the RFC (with clear > data structure boundaries). They're not equivalent as we can avoid adding additional variations in our code by making a breaking change early and iteratively integrating the other various pieces of Relax into existing code. @slyubomirsky also expressed an interest in investigating the dynamic shapes in isolation so I believe this could have some momentum? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/89#issuecomment-1267200112 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/89/c1267200...@github.com>
