-
Notifications
You must be signed in to change notification settings - Fork 63
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
Breaking changes with PCU #433
Conversation
This commit adds a MPI state that's separate from the global variables to the internal pcu_mpi interfaces. The user level PCU interface remains unchanged. However, this change lays the groundwork for PCU2 that will not make use of global state. This is important for some use cases like working around the spectrum-mpi comm_dup bug. The removal of global state also improves testability and modularity of this code.
Throughout the code base it was assumed that the mpi functions were implemented through pmpi and so no other implementation really could have been implemented. This change just removes the complexity from having the vtable.
This commit allows the pcu_mpi to be initialized into a stack variable rather than allways allocating on the heap.
This commit adds a MPI state that's separate from the global variables to the internal pcu_mpi interfaces. The user level PCU interface remains unchanged. However, this change lays the groundwork for PCU2 that will not make use of global state. This is important for some use cases like working around the spectrum-mpi comm_dup bug. The removal of global state also improves testability and modularity of this code.
Throughout the code base it was assumed that the mpi functions were implemented through pmpi and so no other implementation really could have been implemented. This change just removes the complexity from having the vtable.
This commit allows the pcu_mpi to be initialized into a stack variable rather than allways allocating on the heap.
@cwsmith Can you run tests again? Also, the file level doxygen comment that used to be in pcu.c doesn't exist in the new pcu_c.cc file. How can I put it back into the file and make sure it shows up on the scorec doxygen page? There are still unresolved conflicts with the pull request, but I believe the differences are necessary. |
/runtests |
The following should work:
You can then run 'make doc' (assuming the |
Build Log |
@flagdanger where are we at with the documentation we discussed here: #433 (comment) Also, looks like there are still some conflicts. Please make sure that the merge has been completed and let us know if you need help finalizing the merge. |
@jacobmerson I can make a draft of documentation at 6 today. Might need review or changes. These conflicts are sticking around after the first merge. I can try again. |
Cameron and I can work on helping with the merge if needed. Make sure to sync your develop branch with SCOREC/develop before the merge |
- My rationale is that these are old ad-hoc tests. - Removed B737 test as well. The CRE is not available so it should not be a test. Signed-off-by: Aiden Woodruff <[email protected]>
fixes SCOREC#465 running valgrind memcheck on a 28M upright mesh generation on 16 ranks reports no leaks on all ranks ==1567914== HEAP SUMMARY: ==1567914== in use at exit: 40 bytes in 1 blocks ==1567914== total heap usage: 293,194,361 allocs, 293,194,360 frees, 27,011,094,588 bytes allocated ==1567914== ==1567914== LEAK SUMMARY: ==1567914== definitely lost: 0 bytes in 0 blocks ==1567914== indirectly lost: 0 bytes in 0 blocks ==1567914== possibly lost: 0 bytes in 0 blocks ==1567914== still reachable: 40 bytes in 1 blocks ==1567914== suppressed: 0 bytes in 0 blocks ==1567914== Rerun with --leak-check=full to see details of leaked memory
Suppress warning by casting to void. Signed-off-by: Aiden Woodruff <[email protected]>
- Moves all of the files that globus uses unto Github. - Moves globus code to separate repository so that it can be reused.
@jacobmerson I tried merging again, it did not make the conflicts go away. |
@flagdanger Cameron and I will work on the merge. Are you set with the documentation changes? |
@cwsmith I think the docs are mostly in order. Take a look and see if there are additional aspects you want. Let's touch base after Thanksgiving to do the final merge. |
The documentation looks good. I reworked the opening description #433 (comment) to be more verbose. I'll resolve the merge conflicts and check the delta wing results. |
Thanks! |
@jacobmerson |
/runtests |
Build Log |
The deltawing test run on piglet (32 procs) was 2.7% slower with this branch (450s) than develop (438s). Each test was run twice and had consistent performance. This seems to be more than 'noise', but I think we should proceed with the merge. Thoughts @jacobmerson ? The respective source for the tests are here: cmake - same flags and options for both builds
partition
run
|
I think we should proceed even if we cannot track that down as I think getting rid of the singleton is quite important. Nothing obvious jumps out to me as what should cause a slow down. Maybe just chasing a pointer instead of having something in global memory? 2% may be hard to see in a debug profile, but it might be worth a try. |
@cwsmith should |
@jacobmerson By default the pumi build system uses
|
Breaking changes with PCU:
make doc
) to generate doxygen based docs or see https://www.scorec.rpi.edu/pumi/doxygen/pcu.html for basic PCU.cc usage