Re: [lmi] Contradictory performance measurements

[Vadim Zeitlin]

On Thu, 8 Apr 2021 15:52:05 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> I'm still inclined to suppose that some perf-like tool could
GC> ingeniously reverse the inlining, deducing which divisions are
GC> due to rounding and attributing them to 'round_to', e.g.:
GC> 
GC>   # x = rint(x,y) / z;
GC>     MUL x,y     # 1 clock
GC>     RINT x      # 1 clock
GC>     DIV x,z     # 30 clocks
GC>     # alternative
GC>   # x = rint(x,y) * recip;
GC>     MUL X,recip # 1 clock

 Perf does show exactly this in the annotated listing of the function where
inlining occurred. But it doesn't show the (non-existent, in the final
binary) function which got inlined and I don't really see how it could do
this in any reasonably efficient way. So you have to look at the caller
function but, of course, in practice it's not really a problem because you
investigate performance in a top-down way anyhow.

GC> BTW, I had thought that as RAM increased to multiple GB, ECC would
GC> become imperative. But I guess cosmic-ray bit flips aren't actually
GC> crashing your machine every few hours, or you'd have mentioned it.

 No, but just yesterday I've had the most unmistakable cosmic ray detection
I've ever seen: a CI build failed because it tried to use the string
"UNDEPLYING" which, unsurprisingly, failed, because it's supposed to be
"UNDERLYING". And the difference between "P" (120) and "R" (122) is, of
course, just one bit which has clearly got flipped.

GC> I'm surprised it runs for you. Here, I get:
GC>   Database key 'MinIssSpecAmt: value 50000 not preserved in conversion to 
5e+06 cents.
GC> The reason is that, given a double D whose value is an exact
GC> integer congruent to 0 (mod 100),
GC>   D / 100.0
GC> is an exact integer, but
GC>   D * 0.01
GC> is not.

 I'd rerun product_files and ran lmi_cli --selftest, nothing else. Do you
see this in the selftest run too? If so, I should probably investigate why
I don't see it here -- but I definitely don't.

 BTW, I don't remember any more, is the decision to use double as
currency::data_type final or do you plan to revisit it, and explore the
possibility of using (long long) int instead later?

VZ

pgphP63SDcXCR.pgp
Description: PGP signature