yade-users team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

>  - add thread number attribute to change the number of thread of interactionLoop dynamicaly during simulations. Also usefull combined with parallel engine (for fine grain tuning of thread number in each subprocess)
>       1. Add thread number to parallel engine, can be changed dynamicaly. Uncouples the number of threads in parallel engines and in slaves. 2. Enable nested parallel regions (disabled on many systems by default) else the parallel engine is doing no good
>
> What does this change with performance, or is it connected to ParallelEngine? [1][2]
It should not give significant benefits(*) in your case. The idea was to
make the thread per engine more flexible and to use parallel engines in
parallel (nested parallelism). Performance tests aside, the real world
application is this: a coupled simulation with particles and fluids.
The fluid solver and contacts detection/computation are independant on
one time-step, so we can run both at the same time with a
ParallelEngine. Actually, both the fluid solver and the interaction loop
can use many threads, which results in many threads in each subprocess.
The problem was: if each parallel regions try to get the maximum number
of threads, it will compete with the other ones and it will give no
good. Now, if you have N threads available, you can distribute them
between the different engines more efficiently. It can also be changed
at runtime, which is nice for profiling.

(*) Maybe one possible use: I remember that sometimes simple things like
ForceResetter are faster in one thread, while interactionLoop is faster
with many threads. When ompThreads will be effectively used everywhere,
you will be able to easily give one thread to ForceResetter and let more
threads to the other engines. It will not give a big boost, though...

Bruno