@comaniac I think I understand where our different approaches are coming from. I was proposing that only the optimal configurations be permanently saved to the config library (like with TopHub) and a temporary log file of tuning configs would be maintained only during a tuning job. Storing all of the tuning history would rapidly result in huge files which I think would be fine in the case of a database but seems unwise for text files (in terms of search performance).
>From my experience using AutoTVM, I often find interrupted tuning sessions >occur while tuning a large multilayer network. In this case, I mostly care >about skipping the layers that have already been fully tuned. Restarting the >partially tuned layer from scratch is often not a significant time penalty in >comparison. I see that this approach is not nearly as good in a workflow that >involves iteratively tuning a network more and more, in which case you would >save a significant amount of time by being able to resume using the tuning >history. A compromise between the two options might be, as you said, making the tuners deterministic. That way by just knowing the number of trials we can determine which configs can be skipped without needing to store the entire history. I don't think this can be made to work with the xgb tuner though (maybe just treat that as a special case?) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/4150#issuecomment-544701150
