How to control numThreads in CPU platform?

[kyleabeauchamp]

So from what I've looked at, the CPU platform always uses the maximum number of threads as determined by getNumProcessors in hardware.h. Is this correct?

If so, would it be possible to let an environment variable override this behavior?

My use case for this would be in Yank where we run replica exchange with multiple simulations on a single CPU. I suspect that I would achieve better performance by running n independent simulations than by running 1 simulation on n threads.

Thoughts?

[VijayPande]

that sounds reasonable -- the default is the max but you can pass a number and openMM will use min(cores_requested, total_detected)

Thanks,

Vijay

Sent from my Phone. Sorry for the brevity or unusual tone.

On Dec 12, 2013, at 1:22 PM, kyleabeauchamp [email protected] wrote:

So from what I've looked at, the CPU platform always uses the maximum number of threads as determined by getNumProcessors in hardware.h. Is this correct?

If so, would it be possible to let an environment variable override this behavior?

My use case for this would be in Yank where we run replica exchange with multiple simulations on a single CPU. I suspect that I would achieve better performance by running n independent simulations than by running 1 simulation on n threads.

Thoughts?

—
Reply to this email directly or view it on GitHub.

[kyleabeauchamp]

PS: let if you've already determined that your threading code gets perfect linear scaling, in which case this request would be less useful.

One other possible use case of capping the number of threads would be to maintain system responsiveness for multitasking systems.

[rmcgibbo]

Would a platform property might be more appropriate than an environment variable? An env variable would make the API similar to OpenMP, but I think a platform property might fit with the rest of OpenMM better.

[stephanmg]

Think so too!

Von Samsung Mobile gesendet

-------- Ursprüngliche Nachricht --------

Von: Robert McGibbon [email protected]

Datum:17.12.2013 12:13 (GMT+01:00)

An: SimTk/openmm [email protected]

Betreff: Re: [openmm] How to control numThreads in CPU platform? (#242)

Would a platform property might be more appropriate than an environment variable? An env variable would make the API similar to OpenMP, but I think a platform property might fit with the rest of OpenMM better.

—
Reply to this email directly or view it on GitHub.

[kyleabeauchamp]

Either works for me
On Dec 17, 2013 6:19 AM, "Stephan Grein" [email protected] wrote:

Think so too!

Von Samsung Mobile gesendet

-------- Ursprüngliche Nachricht --------

Von: Robert McGibbon [email protected]

Datum:17.12.2013 12:13 (GMT+01:00)

An: SimTk/openmm [email protected]

Betreff: Re: [openmm] How to control numThreads in CPU platform? (#242)

Would a platform property might be more appropriate than an environment variable? An env variable would make the API similar to OpenMP, but I think a platform property might fit with the rest of OpenMM better.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/242#issuecomment-30743278
.

[swails]

On Tue, Dec 17, 2013 at 6:13 AM, Robert McGibbon
[email protected]:

Would a platform property might be more appropriate than an environment
variable?

+1

Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher

[jchodera]

I like the idea of a platform property, since this can more easily be changed via the API.

However, the CPU platform could set the default for this property using the environment variable if it exists.

That may be the best of both worlds.

[swails]

PS: let if you've already determined that your threading code gets perfect linear scaling, in which case this request would be less useful.

In light of #323 I would say being able to control the number of threads externally would be useful in trying to diagnose a possible race condition.

I like the idea of a platform property, since this can more easily be changed via the API.

However, the CPU platform could set the default for this property using the environment variable if it exists.

That may be the best of both worlds.

Also in light of #323 I cast my support in favor of this idea. Without an environment variable, one has to either change the test program itself to set the number of threads property or change the actual code itself to specify the number of threads to use. It would simplify debugging this latest issue if we could simply issue a command like

export OPENMM_NUM_THREADS=1

to disable multithreading and see if the segfaults go away. I may be going about this debugging thing all wrong, but such a feature would be helpful the way I (know how to) debug. OpenMP uses this approach, and probably for good reason...

[jchodera]

I too support the idea of allowing the user control the number of threads. In my case, it would be useful to run multiple simulations simultaneously on the same system, in which case the number of threads each simulation is allocated should be specified.

How about creating a CPU platform property that controls this, with the default being the number of threads on the system unless an environment variable is set, in which case that number is used as the default instead?

[jchodera]

Just wanted to bump this feature request to allow the user to control the number of threads.

Created SimTK feature request:
https://simtk.org/tracker/index.php?func=detail&aid=1991&group_id=161&atid=436

[kyleabeauchamp]

I think this is already solved, right? (https://simtk.org/tracker/index.php?func=detail&aid=1991&group_id=161&atid=436)

[peastman]

Correct. There's a platform property, and also an environment variable.

[ostrokach]

For the benefit of people arriving here from google, the environent variable for controlling the number of threads started per cpu is: OPENMM_CPU_THREADS. For more info, see the CPU Platform section in the docs.

Is there a reason why the more traditional OMP_NUM_THREADS was not used?

[peastman]

OMP_NUM_THREADS isn't traditional. It's specific to OpenMP. We don't use OpenMP.