Closed matthiasdiener closed 2 years ago
I'm honestly not sure about this. I think there are legitimate (if rare) use cases for kernels with that many arguments, and I think it's kind of presumptuous to tell people how many arguments they should be using. :)
I'm honestly not sure about this. I think there are legitimate (if rare) use cases for kernels with that many arguments, and I think it's kind of presumptuous to tell people how many arguments they should be using. :)
Right, I agree. But we aren't emitting a warning, just logging the values. The limit in this PR (50) is high enough so it will emit few messages even for mirgecom (for reference, autoignition-mpi with nspecies=7 emits two of of those).
If I was an outside user (and, heaven forbid, this package does have those) and I got noisy log nonsense about argument counts, I think I would not be happy.
If I was an outside user (and, heaven forbid, this package does have those) and I got noisy log nonsense about argument counts, I think I would not be happy.
Are there ways to reduce the noisiness? E.g. wrapping this with __debug__
.
This feature was specifically requested for mirge development and it is not easy to add this functionality by hand (as pyopencl is kind of hard to build). We already have lots of other debug messages that are quite noisy imho (e.g. the long build time messages).
This feature was specifically requested for mirge development
Requested? By whom? And why is this actionable and worthwhile as a message? And why should we prioritize mirgecom's needs over the everyone else's?
We already have lots of other debug messages that are quite noisy imho
I find that the ones that we do have well-justified. If you've got counterexamples, please list them.
(e.g. the long build time messages).
For example those: A user might be wondering what their code is doing if a compile is taking a while. Those log messages (at the INFO level, so not shown by default) provide an explanation.
To be a bit more explicit, and to avoid spending further time on this: This isn't happening.
This helps with debugging how argument counts increase, even at a point where they are not yet close to the device limit.