search

inducer / pyopencl

OpenCL integration for Python, plus shiny features
http://mathema.tician.de/software/pyopencl
Other
1.05k stars 240 forks source link

log large argument counts #564

Closed matthiasdiener closed 2 years ago

matthiasdiener commented 2 years ago

This helps with debugging how argument counts increase, even at a point where they are not yet close to the device limit.

inducer commented 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. :)

matthiasdiener commented 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. :)

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).

inducer commented 2 years ago

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.

matthiasdiener commented 2 years ago

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).

inducer commented 2 years ago

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.