You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tvm.apache.org by Pzq via Apache TVM Discuss <no...@discuss.tvm.ai> on 2021/12/19 09:29:44 UTC
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Better tvm logger in C++ side
For now, tvm uses the dmlc log in `dmlc-core` by default, which lacks good log level management. Below is some underperformance in tvm.
1. `LOG(INFO)` shares the same severity with `LOG(WARNING)` and `LOG(ERROR)`,
2. `LOG(DEBUG)` does not exist. Instead, tvm contains a macro `TVM_LOG_DEBUG` and an environment `DMLC_LOG_DEBUG` as a log trigger to print the debugging messages, which is quite confusing for users,
3. Tvm is supposed to have an env `TVM_BACKTRACE` as discussed in https://github.com/apache/tvm/issues/9567, but this environment is not working and can not be found anywhere in C++ code.
Although tvm allows users to define or pass custom loggers to manage logs on the C++ side, the default dmlc logger is still the most commonly used logger. Thus, it is necessary to imporve the current tvm logger.
In this RFC, I suggest to do the following:
1. add different log severity in `dmlc-core` repo,
2. provide `TVM_LOG_LEVEL` as an environment variable to unify these env variables or macros, like, `DMLC_LOG_DEBUG`, `TVM_BACKTRACE` and `TVM_LOG_STACK_TRACE`.
cc @junrushao1994
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-better-tvm-logger-in-c-side/11734/1) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/484fe33ed0f87d5a614b632f425d63fcca7aaa4aadf739d069d03e63f85241fd).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Better tvm logger in C++ side
Posted by "Leandro Nunes (Arm) via Apache TVM Discuss" <no...@discuss.tvm.ai>.
I think this is a great initiative @pzq. The only suggestion I'd put on top of it, is that we also can make the Python side to - generally - respect the same rules, environment variables, etc. Just to keep in mind that we can offer a better experience for our users if these rules apply more widely in TVM.
Happy to help exploring these ideas.
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-better-tvm-logger-in-c-side/11734/2) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/d6a80ee70350a7dc662d08d3a4b6793c7afaa2a7992a7694b5c53a36347fbb83).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Better tvm logger in C++ side
Posted by "Cody H. Yu via Apache TVM Discuss" <no...@discuss.tvm.ai>.
I like this proposal a lot. Here are my two cents in terms of use cases.
In the C++ side, PyTorch has two logging systems:
- `LOG(LEVEL)`: This is what we familiar with, including DEBUG, INFO, WARNING, and FATAL.
- `VLOG(INT_LEVEL)`: This is only for debugging, `INT_LEVEL` could range from 0 to 10. They use the following way in Python to control the level:
```
from caffe2.python import workspace
workspace.GlobalInit(['caffe2', '--caffe2_log_level=-4'])
```
I personally like the idea of this system because a single level of `DEBUG` is too broad. I could imagine that I will get lost in the log sea when executing with `DEBUG`. Meanwhile, even we provide 10 levels of debug logging, it is still confusing for both developers and debuggers about what level to put and what level to set.
Ideally we might combine all good ideas as follows. Note that this is just an example.
```
DLOG(FuseOps)(1) << "message"
```
- DLOG stands for "debug log".
- `FuseOps` indicates the log type to differentiate other logs. Note that this is also understand a namespace `relay.transform`.
- `1` is the debug log level ranging from 1 to 5.
- This log can be enabled by setting either environment variable or Python global logging. In this example, we may use `set_debug_log_level("relay.transform.FuseOps", 1)` to enable it.
- Similarity, we may use `set_debug_log_level("relay.transform", 1)` to enable all debug logs under a higher level of namespace.
On the Python side, as @leandron pointed out, we should also make it consistent as possible. Currently, most Python logging are directly by the global logging (i.e., `logging.info("message")`). This would be an issue especially working with other Python packages. Specifically, if another Python package with its own custom logging, the custom settings might be messed up when importing tvm.
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-better-tvm-logger-in-c-side/11734/4) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/ce7431ccb75609f994a736b6cbeaf390e093d37f4e707ea70562dfab1c68fe17).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Better tvm logger in C++ side
Posted by Junru Shao via Apache TVM Discuss <no...@discuss.tvm.ai>.
Another idea @zxybazh and I have been discussing is the possibility to unify Python and CXX logging system via packed functions, i.e. the CXX logging system could potentially call back to python's logging module
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-better-tvm-logger-in-c-side/11734/5) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/4494f59af103f1798a6431ca8befa53745708e8e1f684cdb445d244cba4ed845).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Better tvm logger in C++ side
Posted by Junru Shao via Apache TVM Discuss <no...@discuss.tvm.ai>.
This is definitely extremely important! I would love to further discuss with you on the environment variables used here. Do you think it’s possible to unify DMLC_ and TVM_ environment variables? Is it possible to minimize the number of env variables to use? Is there any precedent we could refer to?
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-better-tvm-logger-in-c-side/11734/3) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/cda9ad0867dc924b7a75a13c3a3b8240244314accb1ef396a39d5df54880517b).