> - 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 _______________________________________________ Mailing list: https://launchpad.net/~yade-users Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
