
Matt Borland wrote:
Here are some preliminary results:
All tests run on an i9-11900k with Ubuntu 24.04 and the Intel(R) oneAPI DPC++/C++ Compiler 2025.0.4 (2025.0.4.20241205). The Intel benchmarks are written in C but should be a faithful port. Bottom line up front is the Intel library is an order of magnitude faster.
Intel
===== Comparisons ===== Comparisons <Decimal32 >: 73831 us Comparisons <Decimal64 >: 76725 us
...
Proposal and built-in types
===== Comparisons ===== comparisons<float >: 73013 us comparisons<double >: 104019 us comparisons
: 562165 us comparisons : 592997 us
I took a look at operator< https://github.com/cppalliance/decimal/blob/069c26a111b33123e6ce5c34b4bb0077... https://github.com/cppalliance/decimal/blob/069c26a111b33123e6ce5c34b4bb0077... https://github.com/cppalliance/decimal/blob/069c26a111b33123e6ce5c34b4bb0077... and I think it can be improved somewhat - unless I'm missing something subtle. Assuming normalized numbers (which should be the case) of the same sign, operator< is equivalent (NaN notwithstanding) to comparing the two integers eeeeeeee... mmmmmmmmmm... I'm not quite sure whether zero needs to be a special case here. There's special case logic in operator< for it, but I'm not positive it's needed. This makes me wonder whether { uintNN_t exp_and_mant; bool sign; } wouldn't be a better representation for _fast, although that would depend on how important comparisons are, performance-wise. We can actually apply a similar trick to BID encoding, by first checking whether the exponents start with something other than 11. In that case, we can use a single compare without having to unpack. (And if not, do something else clever :-) )