Re: [lmi] Would manual optimization help here?

[Vadim Zeitlin]

On Sat, 27 Mar 2021 18:47:49 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

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

 I think perf might well be able to measure the difference, even if it's
true that "selftest" almost surely can't (and I shouldn't have proposed
it, sorry). If you think it's worth actually checking this, I could add
this to my TODO list, this shouldn't take long to do.

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

 Sorry if I've somehow implied that this was my own discovery -- this is
not at all the case and I'm pretty sure there must have been multiple
chapters and books already written about it (or at least tweets and blog
posts). The corresponding data structures are usually called AoS and SoA,
i.e. use "array" rather than "vector", but it's exactly the same thing.

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

 I have to say that it's not the first time I suffer from cognitive
dissonance due to the fact that, on one hand, performance is clearly
supposed to be important for lmi, but OTOH, we don't really do anything to
improve it, even if it sometimes seems that it wouldn't be that hard to do
it. Of course, I could be wrong about this particular optimization, but
things like using SSE instead of x87 under MSW really should provide
important performance gains without even spending much time on it, and yet
we still haven't done it, even though I must be complaining about this
since at least a decade. And the MemberSymbolTable speed up patch from
https://github.com/let-me-illustrate/lmi/pull/114 is more than 6 years old
by now. I realize that there are many other priorities, but it still
surprises me that this one is so far down the list.

 So, to return to this code, while I'd be glad to look at it (because I
definitely need to understand it better, before doing anything else) and
trying to optimize it, I'm just not sure if doing this is going to be
really useful or if it would just end up being one more thing I annoy you
about.

 Please let me know if I should try to do anything here,
VZ

pgp7swWXT2ct8.pgp
Description: PGP signature