Replace get_v3, get_odd_straight and gradient Fortran calls with numpy matrix products - #427
Draft
psavery wants to merge 1 commit into
Draft
Replace get_v3, get_odd_straight and gradient Fortran calls with numpy matrix products#427psavery wants to merge 1 commit into
psavery wants to merge 1 commit into
Conversation
…y matrix products Profiling the PdH 4x4x4 example showed these three SCHAModules routines spending their time in serial loops that are really matrix products: - get_v3: 13.8 s -> 0.9 s (averaged one chunk of configurations at a time to bound memory; the per-element error the Fortran routine computed was never returned to the callers and is skipped) - get_odd_straight: 22.9 s -> 1.4 s - get_gradient_supercell_new: 0.47 s -> 0.16 s at N = 1000 (its OpenMP pragmas are commented out upstream) The helpers reuse the Fortran get_emat, get_g and get_upsilon_matrix for the small input matrices. All outputs match the old implementation to 1e-14 on the PdH ensemble. The include_v4 and fast_grad branches are unchanged, and the replaced Fortran routines are left in place. The speedups do not depend on numpy's threaded BLAS. On a 120-atom test cell forced to a single thread (like a one-core cluster job): get_v3 102 s -> 2.6 s (the Fortran OpenMP also drops to one core), get_odd_straight 13.0 s -> 2.3 s, gradient 0.35 s -> 0.07 s. With the matching CellConstructor change the PdH hessian example goes from 224 s to 24 s (peak memory 1.5 -> 3.4 GB). Signed-off-by: Patrick Avery <patrick.avery@kitware.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Profiling the PdH 4x4x4 example showed these three SCHAModules routines spending their time in serial loops that are really matrix products:
The helpers reuse the Fortran get_emat, get_g and
get_upsilon_matrix for the small input matrices. All outputs match the old implementation to 1e-14 on the PdH ensemble. The include_v4 and fast_grad branches are unchanged, and the replaced Fortran routines are left in place.
The speedups do not depend on numpy's threaded BLAS. On a 120-atom test cell forced to a single thread (like a one-core cluster job): get_v3 102 s -> 2.6 s (the Fortran OpenMP also drops to one core), get_odd_straight 13.0 s -> 2.3 s, gradient 0.35 s -> 0.07 s.
With the matching CellConstructor change the PdH hessian example goes from 224 s to 24 s (peak memory 1.5 -> 3.4 GB).
The other half of this is SSCHAcode/CellConstructor#125