Small optimization in CoordinationBase

Iximiel commented 4 months ago

Description

I changed how the couples are traversed in the CoordinationBase calculate() method, by passing from a "striped" traversal to a "block" one. I get a 3%-5% speedup on my local machine.

Here are some results I got on my workstation, the graph show the time spent in calculate() relative to the time spent in calculate in the master branch

for 4 mpi processes and 2 threads each one

for 1 process with 8 threads (Here I did not expect performance improvement)

Before removing the draft status I'd like to see if it is possible to not store the couples in the neighbor list if the user asks for a fixed list

Target release

I would like my code to appear in release 2.10 (but I think this can rebased on 2.9)

Type of contribution

[X] changes to code or doc authored by PLUMED developers, or additions of code in the core or within the default modules
[ ] changes to a module not authored by you
[ ] new module contribution or edit of a module authored by you

Copyright

[X] I agree to transfer the copyright of the code I have written to the PLUMED developers or to the author of the code I am modifying.

[ ] the module I added or modified contains a COPYRIGHT file with the correct license information. Code should be released under an open source license. I also used the command cd src && ./header.sh mymodulename in order to make sure the headers of the module are correct.

Tests

[ ] I added a new regtest or modified an existing regtest to validate my changes.
[ ] I verified that all regtests are passed successfully on GitHub Actions.

GiovanniBussi commented 4 months ago

I think you get an improvement also with pure openmp because also in that case the access to continuous memory is faster

Iximiel commented 3 months ago

Before removing the draft status I'd like to see if it is possible to not store the couples in the neighbor list if the user asks for a fixed list

I think it may be a better idea to do that in a separate PR

If you think it may be better to try another benchmark I'll do it, otherwise, I think it can be merged/rebased on 2.9

GiovanniBussi commented 3 months ago

I think we can merge it. It can even go to v2.9 because the change is minimal.

Iximiel commented 3 months ago

Ok, then I'm rebasing this to the v2.9

Iximiel commented 3 months ago

I changed the base and I pushed for the CI. while the CI is running I'm also comparing the branch with the master v2.9

plumed / plumed2