Avoid yelling about thread pinning twice
When running without using all threads, the latest changes now produces double pinning warnings, covering 6 lines on stderr:
NOTE: The number of threads is not equal to the number of (logical) cores
and the -pin option is set to auto: will not pin threads to cores.
This can lead to significant performance degradation.
Consider using -pin on (and -pinoffset in case you run multiple jobs).
NOTE: Thread affinity was not set.
#1 Updated by Szilárd Páll over 2 years ago
Why is this "yelling" and how is worth a "high" priority bug report when the previous silly message has been telling users the affinity setting "failed" (an expected by design outcome) was not important for >1 year?
Unless this requires no code redesign (which I'm not sure it doesn't), I think this is at best a normal to low priority feature.
#3 Updated by Berk Hess over 2 years ago
- Priority changed from High to Normal
This second note is the warning I toned down in https://gerrit.gromacs.org/#/c/7291/ (also reviewed by Erik). I mentioned in the discussion there that this setup with sometimes double notes is awkward, but that it requires code reorganization or passing around if we warned before to avoid double notes. Also the tests would need to be updated for that. (Note that the situation is much worse in release-2016 without my change.)
#4 Updated by Erik Lindahl over 2 years ago
In that case the obvious solution is to move the first note so it only goes to the log, and try to add a "(see log)" for the second one.
No matter how important performance might seem to somebody tuning the code, it is NOT the only thing relevant to somebody running a simulation, and it cannot dominate all output. In the present form, we will write double notes using six lines of output for every single run where a user chose not to use all cores in a system.
IMHO, that is no longer friendly help, but overloading the user with non-critical information.