[TVM Discuss] [RFC] Canonicalizing AutoTVM Log Format

[An Wang via TVM Discuss <no...@discuss.tvm.ai>]

@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 community but will defer to other takes.





---
[Visit Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/2) 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/21b65f429a736058a3f430eed8a133cc22459214dfce5164e2603fb350d01320).

[TVM Discuss] [RFC] Canonicalizing AutoTVM Log Format

["Matt Welsh (OctoML) via TVM Discuss" <no...@discuss.tvm.ai>]

Since this is intended as an interchange format, I would strongly advocate for using an industry standard, rather than relying on serialized Python objects. Protobuf would be my first choice. This enables ingestion and processing of AutoTVM logs by tools not written in Python, and provides for versioning, the ability to add, change, and deprecate fields, strong typing, and so forth -- all things that may not be on the radar screen right now, but no doubt will be as the content of the logs evolves over time.





---
[Visit Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/3) 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/d527f5383c618626cff498dac16c9c3addb9dab4193fb48c028071661afb7f75).

[TVM Discuss] [RFC] Canonicalizing AutoTVM Log Format

[tqchen via TVM Discuss <no...@discuss.tvm.ai>]

Given that the format will likely evolve in ansor. We might need to leave certain fields opaque, and keep things in the top level for now.

In particular, the current top level fields include:

- input (describes the computation, or workload)
- config (decribes the set of schedule configs to apply to the workload)
- results (performance result)
- version

The specific definition of input, config can change as we evolve from AutoTVM to Ansor.  The results remains relatively stable so that is what we can discuss and nail down. It might be interesting to also think about what are the non-opaque part from the input.  Perhaps we can first agree on the top level schema and as the config/input becomes more cleared in Ansor, we refine.





---
[Visit Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/4) 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/0f2c006fcd6252c0ebd845aa939b5ad6cb9f9c054b71eddbd283569369b33f86).