#### General Comments
IMHO, @merrymercy's comments on log files are valuable. Many users now look 
into the log file for the information they need, and even manually modify some 
logs for experiments or optimizations. This can be achieved because 1) the log 
files are in text format, and 2) one config (line) in a log file is in a 
reasonable length. As a result, at high level I agree with @anwang's proposal 
that keeps the log file in JSON format but uses proto-generated schema to 
(de)serialize it. IIUC, this approach still allows users to modify the log file 
manually if needed.

On the other hand, one point I have for the current proposal is for `workload`. 
In terms of the semantic, the `workload` mentioned in the proposal is more like 
a `task`, as it has `task_name` and `args`. A workload should be a list of 
input tensors which is independent to tasks. Here is a complete example of 
conv2d task:

```
"task": {
  "task_name": "conv2d_NCHWc.x86",
  "args": [{"tensor": {"name": "data","shape": [1,3,224,224],"dtype": 
"float32"}},
           {"tensor": {"name": "weight","shape": [32,3,3,3],"dtype": 
"float32"}},
           [1, 1], [1, 1, 1, 1], [1, 1], "NCHW", "NCHW", "float32"]
}, 
```

In addition, one problem is that `args` is just a list of task arguments, so 
it's hard for people to understand the actual meaning. I'd be great if we could 
also improve the task initialization process to take keyword arguments instead 
of position arguments. As a result, we could have:

```
"task": {
  "task_name": "conv2d_NCHWc.x86",
  "args": {"data": {"tensor": {"name": "data","shape": [1,3,224,224],"dtype": 
"float32"}},
           "weight": {"tensor": {"name": "weight","shape": [32,3,3,3],"dtype": 
"float32"}},
           "strides": [1, 1],
           "pooling": [1, 1, 1, 1],
           "dilation": [1, 1],
           "data_layout": "NCHW",
           "output_layout": "NCHW",
           "dtype": "float32"}
}, 
```

#### Ansor's Log Format
As @merrymercy mentioned, since Ansor is targeting to a subgraph instead of a 
single operator, the `task_name` would be an issue. The current approach using 
hashed subgraph is definitely not user friendly, and we cannot re-establish the 
subgraph by interpreting its hash value. A better solution would be providing a 
utility to serialize compute DAG as a string, and another utility to 
deserialize the string back to the compute DAG.





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

Reply via email to