[TASK] [DEBT] Use GLOG in the cuML's back-end

[cjnolet]

I have spoken with some of the other back-end developers of cuML about this. GLOG is Google's logging tool for C++.

Similar to other logging tools, it allows us to set a log level at run-time in order to debug cuML algorithms without having to rebuild each time.

It will also allow users of the community to drop the log level to debug when they experience problems and provide their output on github issues so we can help isolate problems more easily.

[burlachenkok]

Sometime ago I worked in things relative to append logging infrastructure to RAPIDS:

Repository:
https://github.com/burlachenkok/cuml/commits/Work_on_RAPML_29

Change:
burlachenkok@5dc14b9

[teju85]

Marking this as a Tech Debt item so as to help as plan for future clean-up releases.

[teju85]

@jrhemstad has recently filed a PR under RMM proposing to use spdlog as the underlying logging library.

Since we depend on RMM, we should do either one of the following:

1. check if we can safely mix loggers, in case we want to go ahead with glog
2. use spdlog instead of glog

Personal opinion: I'd favor spdlog.

[jrhemstad]

I looked at glog and didn't like it because it wasn't header only. That's less of a big deal for a compiled library like cuML. This was more important for RMM since we're planning to make it header only.

See https://github.com/gabime/spdlog/wiki/How-to-use-spdlog-in-DLLs about mixing loggers in different libraries. They shouldn't collide at all.

[teju85]

@jrhemstad I didn't notice anywhere it being mentioned that we can mix logger objects from different logging libraries itself? Maybe I'm misreading its docs?

[jrhemstad]

@jrhemstad I didn't notice anywhere it being mentioned that we can mix logger objects from different logging libraries itself? Maybe I'm misreading its docs?

You can mix logger objects because the libraries are totally independent. The spdlog that is in librmm.so is totally independent of libcuml.so.

Furthermore, the logger object I'm using in RMM isn't registered with spdlog's global registry of loggers because I don't want it to be visible or used externally. So there is no way you can possibly interact or conflict with the logger used in RMM short of totally rewriting the code.

[teju85]

Great. Thanks for the confirmation @jrhemstad

[teju85]

Closing this one as PR #1867 has now been merged.