stillwater-sc / universal / 32310046653
85%
master: 84%

LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran
Jobs 1
Files 620
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 85.363% (-0.02%) from 85.379%
32310046653

push

github

web-flow 
feat(elreal): precision-to-latency matrix for the block-shape study (#1356)

* feat(elreal): precision-to-latency matrix for the block-shape study

#1188 asks for the recommendation matrix, "for X precision at Y latency pick
FpType=Z", and scopes itself to start once the narrow-host convergence work
lands. Both blockers are still open and were re-verified: characterize.cpp
still hardcodes elreal<double> (#1176), and there is no extended-precision
intermediate host (#1051). The narrow hosts still saturate.

But the issue conflates two matrices, and only one of them is blocked.

The DESIGN matrix -- what a narrow block shape would reach once its series
stops degrading -- is genuinely blocked, because the counterfactual cannot be
measured until #1051 exists.

The DECISION matrix -- given this library as it stands, which type should a
caller reach for -- needs no new implementation, only the measurement that had
not been taken. Sections B and C already gave blocks-to-precision and
time-to-first-block separately; section H joins them into wall time to produce
pi at a target precision.

    target        float    bfloat16     double
    16 digits    5.2 ms     19.4 ms    47.7 ms
    32 digits    5.4 ms     31.1 ms    47.7 ms
    64 digits      --          --       166 ms
    100 digits     --          --       486 ms
    200 digits     --          --       790 ms
    300 digits     --          --       793 ms

This sharpens the MVP's conclusion. It had said narrow block shapes "are not yet
a good precision trade". The latency data says something stronger: they are
DOMINATED, not merely limited.

Narrow hosts genuinely are faster inside elreal -- at 16 digits elreal<float>
beats elreal<double> by ~9x, exactly as a cheaper per-block EFT datapath
predicts. But the range where they win, at most 37 digits for float and 33 for
bfloat16, is a range where dd (33 digits) and qd (64 digits) already deliver the
answer as a compile-time constant, and beat them on arith... (continued)

43046 of 50427 relevant lines covered (85.36%)

6898315.85 hits per line

Coverage Regressions

Lines Coverage ∆ File
8
93.65
 -0.48% include/sw/universal/number/cfloat/cfloat_impl.hpp
Jobs
ID Job ID Ran Files Coverage
1 32310046653.1 620
85.36
 GitHub Action Run
Source Files on build 32310046653