multicore: spawn a thread per core by default
The multicore builds of Charm++ don't have any big tradeoff space between process and thread count, or diversity in node configuration, etc. When launched without any specification of how many threads to use, I think it should default to launching enough threads to fully subscribe the system, rather than just one.
I could see this maybe being switched on by building
--with-production, since development work favors explicit control, while deployment favors convenient defaults that don't require knowledgeable user input.
#1 Updated by Phil Miller over 3 years ago
- Assignee set to Eric Bohm
Assign to Eric B initially, since he's working on process launch configuration stuff intensively. If you agree that this is a good idea, implementing it on hwloc or whatever should be quite straightforward for whoever else it gets assigned to.
#2 Updated by Jim Phillips over 3 years ago
Please do not change defaults (or anything else other than debugging assertions) based on the build flags (like --with-production) as this will only confuse people. If you want control you can backwards-compatibly specify +p <threads>.
If you're going to default to all cpus you should I assume also default to +setcpuaffinity (unless the user specifies +p, in which case default to off as now.)
#3 Updated by Eric Bohm over 3 years ago
I agree that this will be fairly easy to implement once hwloc is integrated. However, changing a default behavior like this may be too surprising.
This would represent a major behavioral discontinuity from the non multicore version. That one behaves as MPI does, single core by default.
This change would bring the multicore build into line with the OpenMP approach, which defaults to thread per core. I'm not sure which approach is more likely to lead to more user confusion.
#8 Updated by Evan Ramos over 1 year ago
Yes, this would be trivial to implement with hwloc integrated. Has there been a consensus on whether or not multicore builds should have this change? It would make use a bit easier for users with that configuration, but it would also introduce an inconsistency with all other Charm++ build types.
#11 Updated by Evan Ramos over 1 year ago
Consensus from the core meeting:
Leave sequential mode as the default at all times.
Add a parameter in the vein of "++auto-provision" that automatically determines values to fully subscribe provided resources.
When run without flags, print a message suggesting this flag (and potentially others), as well as "+p1" to silence it.