@comaniac ~~I will change `workload` to `task`.~~ Since ansor is not op-based,
I think it makes sense to keep the `workload` syntax to prepare for ansor's log
format changes.
I agree that the list-based representation of arguments is less than ideal --
currently it's hard to understand the semantics of any particular argument.
If we go with a "kwargs" approach I think we should not support "arbitrary"
kwargs, since the proto would necessarily need to look like
```go
message Task {
string task_name = 1;
map<string, google.protobuf.Any> args = 2;
}
```
or
```
message Task {
string task_name = 1;
map<string, Argument> args = 2;
}
```
The "arbitrary kwarg" approach doesn't restrict the type of a particular
argument in any meaningful way, and I feel the point of formalizing a schema is
to add these restrictions. I think it would be better to have a full
enumeration of the possible arguments for the task. @comaniac what do you
think? Is the example you provided an exhaustive representation of possible
arguments? If not and you agree that we should restrict possible arguments,
could you provide or point me to where I can find the right enumeration?
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/22)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/email/unsubscribe/72933130888c3eb94a8fa76ba0cc3d9884905064b8885702b15d09dec1fff074).
