You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Much of the memory in the state is used in the hot path to solve chemistry. In our performance benchmarks, we see a large amount of variance compared to some fortran code which solve the same systems with the same numerical routines. The large variance could be due to locality. The fortran data is all stack data allocated in data segment of the program, while the c++ variables are allocated on the heap which could be from each other.
Also, our LU decomposition routines keep a list of ids used to index into various arrays at runtime. All of these are heap-allocated and may not be close to each other.
Fortunately, for any given state, the size of these data members (in both the state and LU routines) will always be the same size, and, after configuration, we should be able to calculate these sizes.
We should consider using a custom allocator which will place all of the members of state next to each other in memory and all the members of the LU routines near each other in memory.
Acceptance criteria
After configuration, the total number of bytes needed for LU and the state are able to be calculated
A custom allocator template is added which can dole memory out to the state and LU
Much of the memory in the state is used in the hot path to solve chemistry. In our performance benchmarks, we see a large amount of variance compared to some fortran code which solve the same systems with the same numerical routines. The large variance could be due to locality. The fortran data is all stack data allocated in data segment of the program, while the c++ variables are allocated on the heap which could be from each other.
micm/include/micm/solver/state.hpp
Lines 46 to 63 in cdfd2e7
Also, our LU decomposition routines keep a list of ids used to index into various arrays at runtime. All of these are heap-allocated and may not be close to each other.
micm/include/micm/solver/lu_decomposition_doolittle.hpp
Lines 47 to 78 in cdfd2e7
micm/include/micm/solver/lu_decomposition_mozart.hpp
Lines 59 to 84 in cdfd2e7
Fortunately, for any given state, the size of these data members (in both the state and LU routines) will always be the same size, and, after configuration, we should be able to calculate these sizes.
We should consider using a custom allocator which will place all of the members of state next to each other in memory and all the members of the LU routines near each other in memory.
Acceptance criteria
Ideas
The text was updated successfully, but these errors were encountered: