Feature #973

multicore: spawn a thread per core by default

Added by Phil Miller over 3 years ago. Updated about 1 year ago.

Machine Layers
Target version:
Start date:
Due date:
% Done:




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.

Related issues

Related to Charm++ - Feature #1173: Automatic process launching, thread spawning, and hardware binding In Progress 08/23/2016


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

#4 Updated by Eric Bohm over 2 years ago

  • Target version changed from 6.8.0 to 6.8.1

#5 Updated by Sam White over 2 years ago

  • Category set to Machine Layers

#6 Updated by Sam White almost 2 years ago

  • Target version changed from 6.8.1 to 6.9.0

#7 Updated by Eric Bohm over 1 year ago

  • Assignee changed from Eric Bohm to Evan Ramos

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

#9 Updated by Evan Ramos over 1 year ago

Bump. Is this something we want to proceed with, and is it important for 6.9.0?

#10 Updated by Sam White over 1 year ago

Bring it up at the next Core meeting, I don't think there's a consensus

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

#12 Updated by Evan Ramos over 1 year ago

  • Status changed from New to Implemented

#13 Updated by Sam White over 1 year ago

  • Status changed from Implemented to Merged

++autoProvision provides this behavior, but we decided that the default of no +p option should remain +p1

#15 Updated by Evan Ramos about 1 year ago

  • Tags set to provisioning

Also available in: Atom PDF