Thanks @manupa-arm .
As mentioned in the last post. I agree with you that there is a tradeoff and python/c++ each comes with its own benefits.
To followup on the choice of S1(specifically on the build and lower API). The tradeoffs are:
- T0: On one hand, putting things in python would offer some flexibility and debugging etc.
- T1: On the other hand, we will want S1 in C++ API in some form, because there are other C++ APIs (CompileEngine) that depends on them.
T1 is the main reason why putting lower/build to c++ is desirable in this case.
But we should also indeed address the point about flexibility offered by python. This is why in my last post I brought up A4 as a key point. Specifically, the reason we are talking about why S1 should go is still because S1 contains a few hundreds lines of monolithic code.
- P0: It is still relatively hard for someone else to reconstruct such a lower pipeline using python API
- P1: The lower/build makes certain assumptions that is not necessarily composable with other transformations.
By keeping A4 in mind, the goal is to solve these Ps by modularizing the APIs. For example, we can create a function that returns a list of default lowering pipelines that can be manipulated through python.
To make an analogy, we can think of S1 like building model configurations(e.g. resnet, mobilenet) in modern ml frameworks. The modern nn frameworks are modular enough so that we can easily build those pipelines in python. Thee “default pipeline” can be constructed through c++ and further manipulated by python as well.
So the goal of python first is to come up modular APIs that makes f S1 as easy as building the nn model in ml framework.