Summary
The self-consistent kinetic matrix build parallelizes over ψ surfaces but scales
sub-linearly — ~2.8× at 8 threads (~35% efficiency). Since this build is the kinetic time
sink (~mpsi·mpert²), the lost efficiency is significant.
Where
KineticForces.compute_calculated_kinetic_matrices:
Threads.@threads for ipsi in 1:mpsi
...compute (mpert × mpert × 6) energy/torque matrices at xs[ipsi]...Measurement (mpsi=257, mpert=27, nl=6, fair rtol_xlmda=1e-3)
| threads |
matrix-build wall |
speedup |
| 1 |
1438 s |
1.0× |
| 8 |
512 s |
2.8× (~35% eff) |
Ruled out
BLAS oversubscription is not the cause: BLAS.set_num_threads(1) was slightly slower
(548 vs 512 s at 8 threads), so the per-surface work isn't BLAS-bound.
Likely cause / suggestion
Load imbalance across surfaces — bounce-averaging cost varies strongly with ψ (trapped
fraction, resonance density growing toward the edge), so a static @threads split leaves
threads idle. Suggest trying dynamic scheduling / finer-grained tasking (or chunking the
surface loop) for the matrix build.
Summary
The self-consistent kinetic matrix build parallelizes over ψ surfaces but scales
sub-linearly — ~2.8× at 8 threads (~35% efficiency). Since this build is the kinetic time
sink (~mpsi·mpert²), the lost efficiency is significant.
Where
KineticForces.compute_calculated_kinetic_matrices:Measurement (mpsi=257, mpert=27, nl=6, fair rtol_xlmda=1e-3)
Ruled out
BLAS oversubscription is not the cause:
BLAS.set_num_threads(1)was slightly slower(548 vs 512 s at 8 threads), so the per-surface work isn't BLAS-bound.
Likely cause / suggestion
Load imbalance across surfaces — bounce-averaging cost varies strongly with ψ (trapped
fraction, resonance density growing toward the edge), so a static
@threadssplit leavesthreads idle. Suggest trying dynamic scheduling / finer-grained tasking (or chunking the
surface loop) for the matrix build.