Using Linkcells to accelerate the NL#1403
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| } | ||
| double value=modulo2(distance); | ||
| if(value<=d2) { | ||
| //neighbors_.push_back({A,B}); |
| //const unsigned elementsPerRank = std::ceil(double(nc)/stride); | ||
| const unsigned int start=0;// rank*elementsPerRank; | ||
| const unsigned int end = nc;//((start + elementsPerRank)< nc)?(start + elementsPerRank): nc; | ||
| //Initialization of List A and B is here beausue the access to them is threadsafe (at the moment of writing this) |
Iximiel
force-pushed
the
feature/combineNLandLC
branch
from
6ab15f8 to
dc376ac
Compare
Iximiel
force-pushed
the
feature/combineNLandLC
branch
from
dc376ac to
aa4dd63
Compare
Iximiel
force-pushed
the
feature/combineNLandLC
branch
from
0b3036c to
948aadb
Compare
|
Let's leave this dangling. This is providing speedup in some corner cases, but in order to use it properly we should either (a) implement proper heuristic or (b) allow the user to control it with an env var or better from the input file. |
|
Here I made some measurements, as usual -v is this branch, with 125 atoms this is slower that the plan NL with the simple cubic, with more atoms it starts to scale more linearly, thanks to the LinkCells: and the histogram to confront the results: In the last commit I added a environmental variable to control this and the architecture in the NL to add this option, I added a toggle method to not add any extra element to the constructor, since changing the option has no impact on the setup, and it will be easier to implement when the NL is used |
|
@GiovanniBussi the nvhpc test and the pycv failed on checking out the repo, I think that rerunnning them will make them pass I do not understand what is happening to the mac tests |
|
@Iximiel only 5 tests are crashing. Are the tests using any of the features you implemented here? There might be numerical issues. Differences seem significant though (I quickly skimmed them) |
|
I do not understand why they pass on linux and intel and not on mac |
3 participants
Description
Hello, I think this is the last (or at least the latest) PR in the NL series.
Fist of all I need to do some extra modification to the code (like compacting and move the new template function in the LC header, and rebasing this on the modifications of #1401, if it gets accepted), but I wanted to show the current state of this to get some feedback.
I tried to combine linkCells with the standard NL algorithm, to see if things will be speed up.
Along the way I rationalized the LinkCells loops into a template function and I tried to parallelize the LC version of the NL.
Here a few graphs, they follow the #1401 nomenclature and I used the same commands
**-vis this PR, and**-noompis this PR with the openmp code for the linkcell commented out.These are the results on the NL algorithm:
The LC-NL "linearizes" the time and, contrary to LC -see below-, this seems to benefit from the omp parallelization.
As we were predicting, you can see the old implementation start faster but scales worse than the new implementation. So I was thinking of keeping the two implementations and decide when use one or another, with the default behavior derived from some measurements that can be overridden by the user input.
These are the timing on LC the
-vhas openmp, the-noomphas the new interface but no openmpI do not think that adding openmp is a good idea to LC, but that was not the point o these modifications. Maybe because it is working directly in the result array.
Target release
I would like my code to appear in release v2.11
Type of contribution
Copyright
COPYRIGHTfile with the correct license information. Code should be released under an open source license. I also used the commandcd src && ./header.sh mymodulenamein order to make sure the headers of the module are correct.Tests