lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Micro-optimization in ledger_format


From: Greg Chicares
Subject: Re: [lmi] Micro-optimization in ledger_format
Date: Fri, 18 Jan 2019 23:28:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 2019-01-18 14:15, Greg Chicares wrote:
[...]
> Corresponding changes to stream_cast<>() result in these
> before-and-after timings in the unit test, where only the
> first line is affected by commit 12cb7b91d:
> 
>   stream_cast     : 3.279e-003 s mean;       3203 us least of 100 runs
>   minimalistic    : 2.585e-003 s mean;       2571 us least of 100 runs
>   static stream   : 1.299e-003 s mean;       1159 us least of 100 runs
>   static facet too: 8.441e-004 s mean;        841 us least of 100 runs
>   same, but IIFE  : 8.469e-004 s mean;        840 us least of 100 runs
> 
>   stream_cast     : 1.915e-003 s mean;       1861 us least of 100 runs
>   minimalistic    : 2.583e-003 s mean;       2568 us least of 100 runs
>   static stream   : 1.528e-003 s mean;       1164 us least of 100 runs
>   static facet too: 8.555e-004 s mean;        844 us least of 100 runs
>   same, but IIFE  : 8.531e-004 s mean;        843 us least of 100 runs
> 
> Why is that latest version only half as fast as the streamlined
> unit test (1861 vs 843 us)? Both have the same improvement; the
> only difference is the fancy run-time error reporting in
> stream_cast<>().
> 
> Next I plan to remove all the experimental unit-test code
> (everything except the first timing line) because in retrospect
> the optimized version seems obviously good.

In commit be88bed, I've removed (in effect) everything except the
first and last timing lines. Somewhat puzzlingly, the best timing
result is now less good:

  stream_cast: 1.907e-003 s mean;       1830 us least of 100 runs
  streamlined: 1.127e-003 s mean;       1124 us least of 100 runs

although the code that line tests is virtually identical. I moved
an initialization to match the order in the updated stream_cast<>(),
but moving it back where it was has no effect.

Vadim, have you any idea why this could be? It seems to suggest
that the updated stream_cast<>() (which is rarely if ever used,
and therefore doesn't matter much) and therefore the updated
ledger_format() (which matters a great deal) may not incorporate
all the improvements we've identified...but I can't see it.

Maybe it's the effect of the impending Super Blood Wolf Moon?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]