[SPH][Setup] allow speculative load balancing during injection#1797
[SPH][Setup] allow speculative load balancing during injection#1797tdavidcl wants to merge 9 commits intoShamrock-code:mainfrom
Conversation
|
Thanks @tdavidcl for opening this PR! You can do multiple things directly here: Once the workflow completes a message will appear displaying informations related to the run. Also the PR gets automatically reviewed by gemini, you can: |
There was a problem hiding this comment.
Code Review
This pull request introduces a speculative load balancing mechanism and adds support for discontinuous HCP lattice generation in the SPH setup. The speculative balancing logic calculates particle counts per patch using a device kernel and MPI reduction to improve load distribution during initialization. Feedback identifies a performance bottleneck in the load-counting kernel, which currently uses a brute-force
| for (size_t j = 0; j < npatch; j++) { | ||
| shammath::CoordRange<Tvec> patch_coord | ||
| = {patch_aabb_min[j], patch_aabb_max[j]}; | ||
| if (patch_coord.contain_pos(pos)) { | ||
| sycl::atomic_ref< | ||
| u64, | ||
| sycl::memory_order::relaxed, | ||
| sycl::memory_scope::device> | ||
| atomic_local_load_values(local_load_values[j]); | ||
| atomic_local_load_values++; | ||
| } | ||
| } |
There was a problem hiding this comment.
The speculative load counting kernel uses a brute-force approach with a nested loop over all global patches for every local particle, resulting in SerialPatchTree is already available and used elsewhere in this file (e.g., line 635) to perform
References
- Refactor duplicated logic into a helper function or lambda to improve readability and maintainability.
| u64 npatch = scheduler().patch_list.global.size(); | ||
|
|
||
| // check if the number of patches has changed, rebuild otherwise | ||
| if (npatch != speculative_last_npatch) { |
There was a problem hiding this comment.
The speculative load values are only recomputed when the number of patches (npatch) changes. However, during the injection process, particles are extracted from to_insert and moved between ranks. If the load values are not updated to reflect the current state of to_insert, the load balancer will make decisions based on stale distribution data, potentially leading to severe load imbalance. The counting logic should be executed whenever compute_load is called to ensure it reflects the current "pending" load.
| scheduler().update_local_load_value([&](shamrock::patch::Patch p) { | ||
| return speculative_load_values.get(p.id_patch); | ||
| }); |
There was a problem hiding this comment.
The speculative load balancing logic currently replaces the patch load value with the count from to_insert. This ignores any particles that have already been successfully injected into the patches. To accurately represent the total expected load for a patch, the speculative count (particles yet to be injected) should be added to the current count of particles already present in the patch.
scheduler().update_local_load_value([&](shamrock::patch::Patch p) {
u64 current_load = scheduler().patch_data.owned_data.get(p.id_patch).get_obj_cnt();
return current_load + speculative_load_values.get(p.id_patch);
});
Workflow reportworkflow report corresponding to commit eb6c610 Pre-commit check reportPre-commit check: ✅ Test pipeline can run. Clang-tidy diff reportDoxygen diff with
|
No description provided.