manupa-arm edited a comment on pull request #62: URL: https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1079276287
> No. As far as Collage is concerned it just calls the abstract CostEstimator::Estimate interface for each candidate partition, and can remain ignorant as to where those costs come from. In the prototype it is hard coded to tune, build and run locally to help us get going. Here at OctoML we'll need to instantiate the interface to connect to our production tuning/running/caching systems. In principle the interface could also be instantiated to some analytical model a la the cascading scheduler, though we're not planning to build one. I'm thinking the CostEstimator object can just be passed into the CollagePartitioner to leave this extension point open. Ack. > I figured I'd at least measure that before adding a fix. But secondly, if someone (the service, the user) is going to go to the trouble of caching the optimal partitioning for a particular (model, targets) pair, why not just cache the built artifact directly and skip all the bother? However let me know if I over simplified and I can add that part back This might enable bring us to down to get the cost estimation but it will still explore the combinatorial partitioning possibilities of subgraphs x backends, right ? (lmk, if I am wrong here). I suppose having the abstraction might help a user to play around with what Collage generates as a base. I would consider that to be a useful feature -- even guide the next generation algorithm we might want to put there. In the absense of that, the user need to tweak the CostEstimator as a proxy. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
