Hi LAMMPS Developers & Users,
I am considering to take up this project and invest some time in developing a simple task-graph based algorithm for scheduling and execution. In simple words, the focus is on launching all the force calculation concurrently using boost threads from Boost C++ Libraries and exploit some concurrency. This idea is driven by the following goals :
-
Have minimal to moderate effect to the existing code base.
-
Use light-weight boost threads to launch concurrent independent tasks.
-
Exploit a bit more node-level parallelism.
-
Provides framework for launching heterogeneous (CPU-GPU) tasks that can compute concurrently on CPU & GPU.
A simple example is to convert the following code snippet :
force->pair->compute(eflag,vflag);
force->bond->compute(eflag,vflag);
force->dihedral->compute(eflag,vflag);
force->improper->compute(eflag,vflag);
Change the above function calls to the following pseudo code:
boost::thread t1(force->pair->compute, eflag, vflag);
boost::thread t2(force->bond->compute, eflag, vflag);
boost::thread t3(force->dihedral->compute, eflag, vflag);
boost::thread t4(force->improper->compute, eflag, vflag);
****** SYNC POINT *****
These function calls execute asynchronously with respect to the main thread. A sync point will update and make sure everything is on track and valid. There would certainly be issues with shared variables (reads and writes) like the force pointer and many more.
It would be great, if anyone from the developers or users community has though of this approach. Appreciate any insights, ideas, suggestions, road-blocks and/or 2-cents.
Thanks,
Abhishek
Hi LAMMPS Developers & Users,
I am considering to take up this project and invest some time in developing a simple task-graph based algorithm for scheduling and execution. In simple words, the focus is on launching all the force calculation concurrently using boost threads from Boost C++ Libraries and exploit some concurrency. This idea is driven by the following goals :
- Have minimal to moderate effect to the existing code base.
- Use light-weight boost threads to launch concurrent independent tasks.
They are not really independent. There are data races and not thread safe function calls.
- Exploit a bit more node-level parallelism.
There is not much to gain due to load imbalance. You would need a much more fine grained management of work units. Check out NAMD and it’s Charm++ based architecture for how to do it.
- Provides framework for launching heterogeneous (CPU-GPU) tasks that can compute concurrently on CPU & GPU.
The GPU package already has this feature.
A simple example is to convert the following code snippet :
force->pair->compute(eflag,vflag);
force->bond->compute(eflag,vflag);
force->dihedral->compute(eflag,vflag);
force->improper->compute(eflag,vflag);
Change the above function calls to the following pseudo code:
boost::thread t1(force->pair->compute, eflag, vflag);
boost::thread t2(force->bond->compute, eflag, vflag);
boost::thread t3(force->dihedral->compute, eflag, vflag);
boost::thread t4(force->improper->compute, eflag, vflag);
****** SYNC POINT *****
These function calls execute asynchronously with respect to the main thread. A sync point will update and make sure everything is on track and valid. There would certainly be issues with shared variables (reads and writes) like the force pointer and many more.
How do you propose to address those data races? Those are the make-or-break point. The USER-INTEL and USER-OMP packages contain quite a bit of code to deal with it.
The only styles worth running concurrently are kspace and pair and that can be achieved even better using the Verlet/split integrator style via MPI.
It would be great, if anyone from the developers or users community has though of this approach. Appreciate any insights, ideas, suggestions, road-blocks and/or 2-cents.
You are duplicating existing functionality without any significant benefit and would add an undesirable dependency on boost.
Axel