@jroesch @merrymercy @tqchen
Here are my own takes:
2. I prefer the more readable but longer format.
3. I prefer to remove `kwargs` as it's unused for cleanliness.
4. I'm unsure how useful the idea of `code_hash` is for developers currently.
5. I think "Log" is more canonical in the tvm com
@mdw-octoml I don't think there's currently enough interest to justify adding
Protobuf as a dependency in TVM. TVM users are used to readable json for their
autotvm logs. If there is more interest from the broader community, we can
revisit this.
@tqchen I feel we may not need to re-discuss th
My thoughts are that the suggested change to add Python structure shouldn't
necessarily depend on what the log format will look like, so I don't think
there is a need to wait for the Ansor log format. (I imagine Ansor coders have
their hands full, and that they'd prefer to consider polish late
I've thought about this some more, and I'm changing my stance with respect to
ProtoBuf. While adding a Python class schema is a less invasive change than
introducing ProtoBuf and allows us to stick to the current log format exactly,
protos do have the added benefit of being language-neutral. A
I think the main benefit of keeping the ProtoBuf opaque is avoiding the
unnecessary effort of fleshing out a schema that will change very soon.
However, since I have a full specification described here already, I prefer to
go ahead with it, unless there other concerns I have missed.
I sugges
addressing @mdw-octoml's points:
- I will add a comment addressing the semantics of the dtype field in the proto.
- I will further refine the spec to avoid Any. I originally included
google.protobuf.Any to capture the current tuple argument semantics, which
seemingly supports arbitrary nesting
@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
I see. Thanks for clarifying @comaniac, I agree with your comments.
Addressing @merrymercy's points:
- One possible solution to the redundancy of repeating items such as target
string would be to encode something like this: `message AutoTVMLogs{ string
target; repeated AutoTVMLog; ...} ` whe
