yade-dev team mailing list archive

[Bruno Chareyre <1112689@xxxxxxxxxxxxxxxxxx>]

Anton,

This pragma is using the env variable OMP_NUM_THREADS (1):

#pragma omp parallel for

This pragma is using a custom number (2):

#pragma omp parallel for num_threads(ompThreads)

The obvious problem with (1) is that in nested parallelism, all process want to use the maximum number of threads.
All engines have the ompThreads attribute after commit [1] to make this more flexible, but the #pragma have not been all modified yet. In fact, only ParallelEngine, InteractionLoop, and FlowEngine have it (grep num_threads). 
NewtonIntegrator, for instance, is still using OMP_NUM_THREADS, because the macro YADE_PARALLEL_FOREACH_BODY_BEGIN does not specify num_threads.

Clearly, it is difficult to imagine Newton working in parallel with something else... but for the sake of consistency (and maybe for changing num_threads dynamically in benchmarks) it would be better to make all engines use ompThreads.
It is not a big deal to put it everywhere, this bug is to not forget.

[1]
https://github.com/yade/trunk/commit/38b67a61fd701f16b68657ec2907ec360ad739df

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1112689

Title:
  ompThreads attribute not used in many engines

Status in Yet Another Dynamic Engine:
  Confirmed

Bug description:
  Although ompThreads is present in all engines due to inheritance, many
  of them will still use OMP_NUM_THREADS whatever ompThreads. It needs a
  scan of all parallelized engine to append this optional argument to
  the OMP pragmas.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1112689/+subscriptions