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
The proto representation looks good to me. I have a couple of suggestions based
on prior experience designing proto-based data formats.
- I recommend the use of enums rather than strings for values that are
constrained to a small, fixed-size set. For example, the dtype field in the
Tensor mes
I see. In my experience, it is worth making this a structured type, even if it
seems painful at first. In the long run, having to maintain custom parsing
logic for just one of your fields (where the others are all structured) ends up
being a maintenance burden. I'm a strong advocate for using
Gotcha. In that case I think it's important to document that the format of the
field is the type string used by numpy.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/18)
to respond.
You are receiving this because you enabled mailing list mode.
To u
