You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tvm.apache.org by GitBox <gi...@apache.org> on 2020/11/09 00:05:53 UTC

[GitHub] [incubator-tvm] comaniac commented on pull request #6882: [AutoScheduler] Tutorial on auto-scheduling a network for GPU

comaniac commented on pull request #6882:
URL: https://github.com/apache/incubator-tvm/pull/6882#issuecomment-723687040


   > Personally, the issue I find is that when commits don't describe the changes they make, it can be hard to determine what patch in history led to a certain change in behaviour (I've been burnt by this a few times now). Generally, I assume 'add tutorial' type commits won't change behaviour unless it's explicitly flagged. If all these changes are required, perhaps a middle-ground would be to flag them explicitly in the commit message?
   
   I agree with your that separating PRs for different functions is important for long-term maintenance, and we should do that for every released feature. However, my point is since we haven't fully released auto_scheduler and the total number of auto_scheduler PRs is just a few, it should be easy to identify the PR that changes the certain behavior (in fact, since currently only a few people using the upstream auto_scheduler, I don't think this would be an issue for now). IMHO, it's fine to follow this principle after auto_scheduler is able to perform end-to-end tuning on all three platforms (x86, ARM, NVIDIA GPU). Meanwhile, my primary concern of separating changes to many small PRs is that it will slower the auto_scheduler upstream process due to the high CI traffic.
   


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org