Right now n, m, p (the domain bounds) are not passed as compile-time constants when --case-optimization is enabled. This is because they are only known once the MPI domain decomposition is complete. However, if one compiles MFC with --no-mpi then these variables are known at compile time!
It would be interesting to see if adding these to case optimization speeds up the code markedly. It seems like this could be the case, since they are used in so many loops.
Doing this experiment would involve creating an experimental branch that adds these variables to case optimization and the simulation codebase (I think some sort of additional minor modifications would be required for this). Then, benchmarking a simulation with case optimization on and then the running same case on the master branch with case optimization on and MPI off.
A caviat is that many loops are not over n, m, p but rather regions that include buffer zones (idxbeg and idxend and its variants). So, it's unclear that this level of compile time optimization would make its way to the most expensive loops (though since weno_polyn is also known as compile time already, those variables could also be known at compile time easily!).
Right now
n,m,p(the domain bounds) are not passed as compile-time constants when--case-optimizationis enabled. This is because they are only known once the MPI domain decomposition is complete. However, if one compiles MFC with--no-mpithen these variables are known at compile time!It would be interesting to see if adding these to case optimization speeds up the code markedly. It seems like this could be the case, since they are used in so many loops.
Doing this experiment would involve creating an experimental branch that adds these variables to case optimization and the simulation codebase (I think some sort of additional minor modifications would be required for this). Then, benchmarking a simulation with case optimization on and then the running same case on the master branch with case optimization on and MPI off.
A caviat is that many loops are not over
n, m, pbut rather regions that include buffer zones (idxbegandidxendand its variants). So, it's unclear that this level of compile time optimization would make its way to the most expensive loops (though sinceweno_polynis also known as compile time already, those variables could also be known at compile time easily!).