Open eschnett opened 12 years ago
Splitting by variable was implemented in e11f056834d3106e84c21c4edfac945a125f3e96. I wrote code last night to split by pattern, which I can commit, but the interface might change in the future. What did you mean by "introduce parameters to choose which routines are called at run time"? Do you mean to include both split and unsplit versions of calculations? This is not currently implemented. I am worried it would lead to a lot of code being generated.
Yes, I refer to being able to choose at run time what version is executed. This either allows dynamic optimizations, or allows choosing different variants on different systems (Intel vs. AMD, depending on L1 cache size).
I hope that we don't need to generate more than a few versions of each routine. Increasing the generated code by a factor of a few would be tolerable.
An alternative may be to generate one version with if statements that select which part (if any) or whether all parts should be executed, similar to the choice of finite differencing order. Then we can call the same routine multiple times with different settings. The code size would not increase, the performance may not suffer much, and dynamic compiling could still specialize the routine. However, this is all but guaranteed to obstruct a static compiler's optimizer from doing anything useful, and also prevents e.g. CSE from working.
Split McLachlan's calculations semi-automatically in two ways: (a) by variable, so that e.g. dot[g] and dot[K] are calculated separately, and (b) by pattern, so that advection terms, dissipation, and "everything else" are calculated separately. Also introduce parameters to choose which routines are called at run time.
This was #582 in the Einstein Toolkit Trac.