Debug output logger

[krasznaa]

I was wondering... Would it make sense to add the ability to get some debug printout from the code if we ask for it?

I'm currently writing code that performs the explicit memory copy of jagged vector data between the host and the device. That code receives a bit of logic, as it needs to figure out how many separate chunks to perform the copy in. (In my current setup, in the most ideal case the copy would happen in 2 operations. Or, if the jagged vector on the host is set up in a less ideal way, in N+1. Where N is the size of the "outer vector" in the jagged vector.) Now I'm wondering how to validate the behaviour of the code in the nicest way.

Of course I can just add std::cout statements while I'm writing the code, and then remove them completely afterwards. But I was wondering if we should add something more elaborate to the code.

Off the top of my head I'm thinking of something like:

void some_elaborate_function(...) {
   ...
   VECMEM_DEBUG_MSG( 3, "Performing the copy in " << n << " chunks" );
   ...
}

Where my thinking is that:

• The macro would only do anything in a debug build, so that optimised builds would skip this code entirely;
• Even in debug builds one would have to set some "global variable" to enable debug logging. Similar to what ROOT does.

This way, just as ROOT, we could assign different verbosity levels to the debug messages. (We could just do the same as ROOT, and assign an integer to the messages as "levels".) Letting the user decide to what detail they are interested in these messages.

What do you think @stephenswat? I think such a functionality could come in handy in a number of places.

[stephenswat]

I like it! Just to provide a bit of contrast with how CUB does it: they allow you to provide a run-time argument to enable debug prints. Now, that has the upside of giving you more flexibility in user code; if for whatever reason you want to get debug prints in your own code, you can. Is that really useful? Maybe. The obvious advantage of doing this at compile time is that it should give us slightly better performance.

I'd say I prefer the compile-time solution, just because I don't believe code like this should ever have side-effects in real use.

[krasznaa]

I'm actually considering a combination of compile-time and runtime decisions about what would be printed. Just because I thought it could be handy if one could activate very detailed printouts for just some calls, while silencing calls that they are not interested in, in their debugging.

I'll put together a proposal, and we can discuss there further about the technicalities. Maybe a fully compile-time driven selection of printed messages will be the way to go after all.

[stephenswat]

Personally I'm not a huge fan of keeping a runtime variable for this, because global state is evil. But if it's only for debugging code then it doesn't really matter.

Just as a matter of design, please make sure that both possible evaluations of the macro "use" its arguments, because of our unused-variables-are-errors policy. 🙂