[lmi] Valyuta performance degredation?

[Greg Chicares]

$ git show 96d02bc3
|Date:   2021-01-07T09:28:26+00:00
|
|    Record timings
|
|    Some degradation is observed, especially for solves. This needs to be
|    investigated.

Extreme TL;DR: don't worry, it's nothing.

This 19x6 matrix tabulates the mean timing for each of the
six 'make cli_timing' measurements, for the last nineteen
'git log --ancestry-path' commits on branch valyuta/004
(i.e., the range from 96d02bc3 (above) back to the earlier
commit that led to the "degredation" comment).

0.02261 0.03921 0.03577 0.006163 0.0219 0.02016
0.02262 0.03873 0.03542 0.006216 0.02192 0.0202
0.02252 0.03882 0.03544 0.006213 0.02192 0.02026
0.02235 0.0389 0.03541 0.006165 0.02186 0.02024
0.02241 0.03875 0.03532 0.006146 0.02178 0.02014
0.02117 0.03823 0.03484 0.006149 0.02154 0.01992
0.02121 0.0383 0.03497 0.006198 0.02173 0.01998
0.02163 0.0385 0.035 0.00618 0.02172 0.01997
0.02125 0.03834 0.03504 0.006173 0.02165 0.02112
0.02148 0.03852 0.03502 0.006191 0.02172 0.02
0.02181 0.03847 0.03504 0.006217 0.02175 0.02001
0.0218 0.03848 0.03511 0.006233 0.02174 0.02005
0.02191 0.03842 0.03492 0.006157 0.02171 0.02005
0.02195 0.0385 0.03519 0.006223 0.0218 0.02006
0.02162 0.03873 0.03524 0.006171 0.02179 0.02007
0.02127 0.0384 0.035 0.006122 0.02162 0.02004
0.02162 0.0385 0.03523 0.006186 0.02191 0.02001
0.02284 0.04086 0.04092 0.006528 0.02178 0.02022
0.02172 0.03867 0.03518 0.006147 0.0219 0.02011

and entry [17][2] (index origin zero), 0.04092, is
apparently just a random outlier; other than that, and
perhaps [17][1], the pattern is very smooth and shows
no actual trend. (I present it this way because it's
very easy to paste into a spreadsheet for graphing.)

I offer these observations:

First of all, here's the script that generated these numbers:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
#!/bin/sh

set -ev

rm -f timings
git checkout -- Speed_gcc_x86_64-pc-linux-gnu
git switch valyuta/004
make $coefficiency uninstall

# for z in cf62b4482 506051ae d4e02914 7930f692 43c85673 96d02bc3 ; do
for z in $(git log --oneline --ancestry-path --pretty='format:%h' 
cf62b4482^..96d02bc3) ; do
  echo "...switching to commit ${z}:"
  git switch --detach $z
#  rm /opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/*.d
  make clean
  make $coefficiency install >log_${z} 2>&1
  make cli_timing
  echo $z >> timings
  cat Speed_gcc_x86_64-pc-linux-gnu >> timings
  git checkout -- Speed_gcc_x86_64-pc-linux-gnu
  echo "...back to master:"
  git switch -
# in case that didn't work:
  git switch valyuta/004
done

echo "Completed."
-->8---->8---->8---->8---->8---->8---->8---->8---->8---->8--

In English: accumulate timings in file 'timings', for each
of numerous commits. Set the stage by uninstalling and
removing the 'Speed_*' file that will be repeatedly
generated. Do this for
  $env |grep LMI_                                                  
  LMI_COMPILER=gcc
  LMI_TRIPLET=x86_64-pc-linux-gnu
because it compiles quickly.

Importantly, use commits in [cf62b4482, 96d02bc3]. At first
(in a commented-out line), I had used every tenth commit in
`git log -51`, which led to confusing results: for commits
in the middle, timings were of a different complexion, and
I think that's because `git log -51` includes some stuff
along a merge path that's irrelevant here; '--ancestry-path'
seems like the perfect thing to use here.

Some of the script lines are best explained by showing the
errors they prevented:

This line:
  git checkout -- Speed_gcc_x86_64-pc-linux-gnu
prevents:

...switching to commit cf62b4482:
error: Your local changes to the following files would be overwritten by 
checkout:
        Speed_gcc_x86_64-pc-linux-gnu
Please commit your changes or stash them before you switch branches.

This line:
  git switch valyuta/004
works around this problem:

/opt/lmi/src/lmi[0]$git switch -
fatal: a branch is expected, got commit 
'd4e029146c6a385820b8952deeabc82558541603'

although I had thought 'git switch -' should just work.

This line:
  make clean
avoid tragic outcomes like:

/opt/lmi/src/lmi[0]$make cli_timing
vector::reserve

/opt/lmi/src/lmi[0]$make cli_timing                     
Segmentation fault

I thought that was impossible, because 'git switch' seems to
'touch' each file it changes, so that 'make' should just work;
but that's not what I observed. What am I missing?

This line:
  #  rm /opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/*.d
attempted to work around another problem that I hadn't
expected to see. I traced it to the autodependency '.d'
files in /opt/lmi/gcc*/build/ship/ , which don't seem to
travel back in time very well. In particular, file
  /opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/interest_rates.d
mentioned 'irc7702_interest.hpp', which was added between
the endpoint commits; because it was included as a prerequisite
in that '.d' file, 'make' attempted to build it; and, this
being linux, it used the rule for binaries like foo$EXEEXT
(which is "foo" for pc-linux-gnu), and tried to invoke the
linker. Anyway, 'make clean' made that unnecessary. Still,
it's quite inconvenient, and I don't understand it. I think
I've followed the method here correctly:
  
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/#advanced
and
  /opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship/interest_rates.d
looks like this:

interest_rates.o: /opt/lmi/src/lmi/interest_rates.cpp \
...
 /opt/lmi/src/lmi/yare_input.hpp /opt/lmi/src/lmi/irc7702_interest.hpp \
 /opt/lmi/src/lmi/math_functions.hpp \
 /opt/lmi/src/lmi/tools/pete-2.1.1/et_vector.hpp \
...
/opt/lmi/src/lmi/yare_input.hpp:
/opt/lmi/src/lmi/irc7702_interest.hpp:
/opt/lmi/src/lmi/math_functions.hpp:

...so I would reason that this discussion:
  
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/#norule
would prevent the observed problem, as 'irc7702_interest.hpp'
has a
  /opt/lmi/src/lmi/irc7702_interest.hpp:
rule in the '.d' file that "ensures make won’t throw an error
since it knows how to handle that non-existent file, and it
ensures that any file depending on that target is rebuilt,
which is exactly what we want."