Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve speed of dump_connections() in layer_impl.h #3160

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

xavierotazuGDS
Copy link

@xavierotazuGDS xavierotazuGDS commented Mar 18, 2024

Instead of calling get_connections() inside a loop for every source node, it calls get_connections() once for all connections between layers.

The code considers that:

  1. source nodes positions (src_vec) is ordered by source node.
  2. connectome is ordered by source node.

fixes #3142

Instead of calling get_connections() inside a loop for every source node, it calls get_connections() once for all connections between layers.

The code considers that:
1) source nodes positions (src_vec) is ordered by source node.
2) connectome is ordered by source node.
@xavierotazuGDS
Copy link
Author

This is a proposed solution for issue #3142

@xavierotazuGDS xavierotazuGDS changed the title Update layer_impl.h Improve speed of dump_connections() in layer_impl.h Mar 18, 2024
@xavierotazuGDS
Copy link
Author

This implementation only works for non-MPI and in some cases (not all) of MPI. Hence, DO NOT USE !!!!

@heplesser heplesser marked this pull request as draft March 18, 2024 21:15
@heplesser heplesser added S: Normal Handle this with default priority T: Maintenance Work to keep up the quality of the code and documentation. I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) labels Mar 18, 2024
@heplesser heplesser added this to In progress in Kernel via automation Mar 18, 2024
@heplesser
Copy link
Contributor

@xavierotazuGDS Thank you for your PR! Since there still seems to be a problem with the code as of your last message, I have converted it to "Draft" status. You can change that back again later.

New version. No bugs. It is a more "conservative" approach, since it does not consider nodes are ordered.
@xavierotazuGDS
Copy link
Author

I have uploaded a new version. No bugs now on MPI. I do not change the Draft status because I am not sure how to do it.

@xavierotazuGDS xavierotazuGDS marked this pull request as ready for review March 18, 2024 23:34
@xavierotazuGDS
Copy link
Author

Status changed from "Draft" to "Open".

Code style modified to agree with clang-format
@terhorstd
Copy link
Contributor

Thanks for the update, xavierotazuGDS!

There are/were still some formatting issues (mostly regarding white-spaces as far as I see), but they need to be fixed to keep code in a consistently formatted state (see Contribute to NEST).

Since you seem to be a first time contributor, please also send a Contributor Agreement to info@nest-initiative.org so we can accept and correctly acknowledge your contribution.

Automatic clang-format checking complains about functions I have not modified.
@terhorstd
Copy link
Contributor

I just saw, that you already did send the CA! My appologies.

@xavierotazuGDS
Copy link
Author

terhorstd,

I believe I solved all my code style issues. The other issues are in methods I have not modified (they are clang-format issues from the original code). Anyway, I could try to solve them (I will need some time).

@xavierotazuGDS
Copy link
Author

I took a look at clang-issues in methods I have not modified, but suggested changes are so big code blocks that I would not know what I am doing. Hence, I prefer not to modify clang-format issues outside the method I modifed.

@terhorstd
Copy link
Contributor

The version of the code formatter changed some time back, this is why there are complaints. Everything is already fixed in the main branch, which your branch is several commits behind (see on the main page of your repo "… behind"). Try to merge those into your branch, that should fix all spots that you didn't touch.

const long tnode_lid = tgt_layer->node_collection_->get_lid( target_node_id );
assert( tnode_lid >= 0 );
tgt_layer->compute_displacement( source_pos, tnode_lid ).print( out );
out << '\n';
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing closing bracket here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

corrected

@otcathatsya
Copy link
Contributor

I ran some basic benchmarks on the JURECA cluster with the following setup:

  • 1 node, 64 threads
  • Scaling number of layers (100x100 grid each) connected to every other layer (and itself) with a 25x25 mask
  • Average over 10 runs, call DumpLayerConnections after each layer connection
Layers Num Total Conns Time Final Memory Branch
1 6.250.000 19.76s 2873MB Improved
2 25.000.000 81.15s 3891MB Improved
4 100.000.000 322.11s 7743MB Improved
1 6.250.000 28.22s 1600MB Master
2 25.000.000 139.72s 2735MB Master
4 100.000.000 1070.84s 6330MB Master

This seems to indicate that it scales pretty linearly, not even increasing memory usage by much

scaling

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: Normal Handle this with default priority T: Maintenance Work to keep up the quality of the code and documentation.
Projects
Kernel
  
In progress
Development

Successfully merging this pull request may close these issues.

Slow DumpLayerConnections()
4 participants