[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?
- Re: [lmi] Micro-optimization in ledger_format, (continued)
- Re: [lmi] Micro-optimization in ledger_format, Greg Chicares, 2019/01/16
- Re: [lmi] Micro-optimization in ledger_format, Vadim Zeitlin, 2019/01/16
- Re: [lmi] Micro-optimization in ledger_format, Greg Chicares, 2019/01/16
- Re: [lmi] Micro-optimization in ledger_format, Vadim Zeitlin, 2019/01/16
- [lmi] Local variable of rvalue reference type [Was: Micro-optimization in ledger_format], Greg Chicares, 2019/01/17
- Re: [lmi] Local variable of rvalue reference type, Vadim Zeitlin, 2019/01/17
- Re: [lmi] Micro-optimization in ledger_format, Greg Chicares, 2019/01/17
- [lmi] Helpful compiler options [Was: Micro-optimization in ledger_format], Greg Chicares, 2019/01/18
- Re: [lmi] Micro-optimization in ledger_format, Greg Chicares, 2019/01/18
Re: [lmi] Micro-optimization in ledger_format, Greg Chicares, 2019/01/18