From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2024-05-31 11:10:12
On Fri, May 31, 2024 at 6:02 AM Matt Borland wrote:
> Glen,
>
> In the past few weeks we've been hammering on adding non-IEEE 754
> compliant fast types to the library that directly store the sign,
> exp, and significand rather than decoding at each step. Additionally
> the fast types will normalize the significand and exponent rather
> than allowing decimal cohorts since accounting for this was the first
> step in each operation (also cohorts are likely of only academic
> interest if the goal is speed). With these changes we found that
> decimal32_fast runtime in the benchmarks is approximately 0.251 of
> regular decimal32 while yielding identical computational results.
> It's the classic tradeoff of space for time since decimal32_fast
> contains minimally 48-bits of state. We will continue to squeeze
> more performance out of the library and add decimal64_fast and
> decimal128_fast, but we wanted to provide some intermediate results.
>
> Matt
Excellent, thanks Matt.
Note that ultimately, as long as the decimal64_fast et cetera types
have conversion functions:
- uint64_t toBID() const; // converts to IEEE 754 BID representation
- uint64_t toDPD() const; // converts to IEEE 754 DPD representation
And if you can construct the decimal64_fast types from the BID64 and
DPD64 representations:
Then I suggest that nobody really needs the non-fast types. :)
i.e. When I want to encode, decode, store that representation I can.
But I would never want to incur the overhead of decoding and encoding
it on every arithmetic operation.
(I can't imagine who would)
Glen