Re: [lmi] Would manual optimization help here?

[Greg Chicares]

On 3/26/21 11:01 PM, Vadim Zeitlin wrote:
> On Fri, 26 Mar 2021 14:59:46 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[... caching a double outside a loop, to avoid indexing a vector inside the 
loop...]
> GC> and my question is whether I should do something similar, adding
> GC> a new 'double YearsDBDiscountRate', setting it once per year
> GC> (say, 100 times for 100 years), and then using it 1200 times.
> 
>  This looks like a simple change to do, so I'm not sure why not just test
> if doing it affects the results of the "selftest"? Answering the desired
> question directly seems more epistemologically correct to me than trying to
> deduce it indirectly.

It's like asking how much my eyelashes warp space-time. In theory,
we can calculate that, but in practice, it's too small to measure
with the generally available instruments.

Here, if there were a sound reason to believe one way is better
than the other, I could rewrite everything that one way, and maybe
the aggregate effect would be large enough to measure. But I won't
do that now, because you've made a suggestion that is likely to
outperform both of the approaches I've tried:

>  One general thing I can say is that using "Year" as index into several
> (many?) different vectors looks very cache-unfriendly. I suspect (but,
> again, without being sure at all without testing) that it could be highly
> advantageous to have a struct containing all the values for the current
> year, which should fit in the cache, that would be filled at the start of
> every iteration of the outer loop in RunOneCell() and then use it in the
> rest of code. I.e. having individual "caches" for some vector elements
> doesn't seem very useful because there are still lookups of the other
> vectors, but if we could avoid using "Year" as index anywhere at all, it
> should be good for performance.

[...or, to put it more epigrammatically...]

> using vector of structs is, generally speaking, much preferable to using a
> struct of vectors, which is what AccountValue is currently.
You could grow that into the "Caching-struct Inversion" chapter of a
bestselling "Design Patterns for a New Era".

Maybe someday we'll rework that code. There isn't much of it (it's
mostly just ihs_acctval.cpp + ihs_avmly.cpp), but that's where lmi
spends the lion's share of run time.