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