Description
For many years now, Chapel has defaulted to using a number of threads equal to the number of physical cores available to the locale (CHPL_RT_NUM_THREADS_PER_LOCALE = MAX_PHYSICAL) rather than the number of hyperthreads (MAX_LOGICAL). At the time we made this decision, it was based on the performance we were seeing in our main benchmarks on our main architectures at that time, which generally seemed to perform best in the MAX_PHYSICAL mode. I believe at the time we attributed this to HPC benchmarks being fairly computationally intensive and so perhaps not benefitting from hyperthreads as much as interactive desktop applications (say).
Since that decision was made, time has passed and architectures, system software, and Chapel have all evolved and improved. Meanwhile, we've also become interested in new benchmarks. To that end, this issue asks whether the decision we made then is still the right one for today? It's motivated by the fact that from time-to-time, use cases come up where hyperthreading has proved beneficial to Chapel performance.
To that end, it could be worthwhile to re-evaluate this choice of default on current systems, benchmarks, and software versions.
Even the performance results didn't obviously indicate that switching the default was the right move, it could still be a reasonable change to consider since many users seem to expect a number of threads equal to their hyperthreads and are confused when we don't use that many. And at least some parallel software seems to default to #hyperthreads as well, which would remove a difference between Chapel and behavior that might be considered "typical" or "most likely."