Re: [lmi] [lmi-commits] valyuta/000 e9efb62: See 'README.branch'

[Vadim Zeitlin]

On Tue, 11 Aug 2020 18:08:44 -0400 (EDT) Greg Chicares 
<gchicares@sbcglobal.net> wrote:

GC> branch: valyuta/000
GC> commit e9efb62472281faac7965276adc1eb148c20fc4a
GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> 
GC>     See 'README.branch'

 Hello,

 I'm not sure if I'm even supposed to look at it already, but after doing
this quickly, I have a couple of contradictory remarks:

 First, I'm really surprised that the version using the currency class runs
twice slower than the version using doubles. With an optimizing compiler,
abstraction penalty should be at most a few percents and I'd expect it to
be more than compensated by the gain of speed due to using integers instead
of doubles. Would it be worth trying to profile both versions to see where
does this slowdown come from? Of course, in the grand scheme of things we
know that to achieve anything close to the maximal theoretical performance
we need to explore parallelism, either by using threads, or by using SIMD,
or, ideally, both of them, and no amount of single-threaded code
optimizations can result in anything comparable, but perhaps we could still
at least avoid making things slower.

 Second, and going in a completely opposite direction, I'm also somewhat
surprised that you didn't use this opportunity to add checks for integer
overflow to the various operations. This is, of course, very unlikely to
happen, as 64-bit integers can represent amounts up to ~92 quadrillions,
but I half-expected you to still care about this possibility.

 Sorry if my reaction was too hasty and so this email wasn't useful. OTOH,
if you did expect me to look at this code, I probably need to do it again,
more closely, so please let me know if I should.

 Thanks,
VZ

pgpLX71NbH25t.pgp
Description: PGP signature