esum is slow

[zingale]

We use esum() to do exact sums of specific terms in the RHS of the ODEs to prevent roundoff. But esum() is slow. At the moment, we have a general routine with a large max_esum_size -- this also causes trouble on the GPUs.

We should experiment with creating specific esum() routines for the number of terms involved, e.g., esum3(), esum4(), esum5(), ...

We know this ahead of time, since we are explicitly calling esum() on specific combination of terms in rate equations.

[zingale]

we should also try to mark this function as pure and get it inlined

[zingale]

the esum algorithm comes from here: https://people.eecs.berkeley.edu/~jrs/papers/robustr.pdf

[zingale]

it is also not clear if enum makes sense with just 2 numbers. Is it really better than just a + b

[zingale]

the esum branch removes all the esum() calls with 2 elements in aprox13. This gives identical results to the original version when using test_react (as compared with fcompare). This suggests that for 2 elements, it does not matter.

The code is about 3% faster w/o the esum() on 2 elements.

I'm going to try to do a custom sum for 3 elements next.

[zingale]

PR #65 addresses some of this

[zingale]

should this still be open?

[maxpkatz]

I think it should still be open. We still have improvements we can make.

[maxpkatz]

Closing, I've done all I plan to do on esum at the moment -- the optimizations we've already thought of have been done, and new ones can be in a new issue.