Thanks @kevinthesun and @comaniac for the responses! > I'd prefer to keep the current AutoTVM dispatch context
I'm not intending to replace the existing dispatch context, only provide some syntactic sugar. We could just override the `__enter__` method of ConfigLibrary to do `apply_history_best`. I think it would be more intuitive than extracting the relevant .json file and passing explicitly. > If we design this resume logic in a general way, we can also extend it to > tophub. Does it make sense to generalise here? As far as I can tell, TopHub doesn't store tuning history just optimal configs, so there's no way to 'resume' a TopHub tuning session. In some way we have to determine whether the existing 'tuning effort' to produce a particular config is sufficient and number of trials is the only obvious way I can think of characterising this. I'd be happy to look at any alternative implementation idea though. > We can try to retrieve the target device info using system call and add it to > every record when dumping to file/database. This would be a good start, but I think this needs to also be something a user can fully specify. For instance, we might be interesting in driver versions, memory clock speeds or even physical parameters such as board cooling. Which system calls were you considering using to determine the platform? Perhaps have a default method that relies on these calls with the ability to pass additional arbitrary info to `config_library.start_job()`? > In my personal opinion, we also need to invalid the history/records when TVM > has been updated I agree with this, but maybe it can be included as part of the previous point on board configuration? In a general sense we need an idea of whether a particular config is 'compatible' with our current platform and I think it's reasonable to include TVM version as a part of this. -- 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-544433748
