Re: Decimal: Formal review begins

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2025-01-20 21:31:38

On Mon, Jan 20, 2025 at 12:53 PM Ruben Perez via Boost <
boost_at_[hidden]> wrote:

> Glen, thanks for pointing this out. In the sight of this new piece of data,
> I'm afraid I will be adding a new condition to my ACCEPT vote: the library
> should be optimized to be in the same order of magnitude of performance as
> the Intel one.
>

Disclaimer: Alliance employee

I think it's good that Glen pointed out we need to be benchmarking and
comparing ourselves to the current pack leaders but I'm hesitant to make
performance targets acceptance criteria.

If you actually sit down and look at how long Intel's DFP library has been
around, it seems like version 1.0 came out in 2009.

That gives the library a literal 16 years of a head start here.

Performance is also a moving target and what's more, hyper-optimized code
is hard to read for us normies who aren't experts in computational
techniques. I think for a Boost review, we should be mindful of the current
performance and where it stands. But we should also remind ourselves that
we're also reviewing the author as well. The question comes down to: do we
trust that Matt and Christopher are going to iterate on the implementation?

Personally, I'd say that I trust Matt because I've conversed with him in
the past. So that's at least half the battle right there.

Hash2 has functions much slower than OpenSSL's implementations, which are
all these behemoths written using hand-crafted assembly. But we're actively
working on closing the gap. And what's more, Unordered didn't always have
the fastest hash tables either. Instead, the library slowly evolved over
time as new techniques and research became published and used by industry.

>From what I can tell, Decimal has well-defined use-cases, its license is
more permissive than its competition, it's constexpr, it's C++-first.
Saying "just use the C library" always sounds good on paper, but it winds
up being a lot lamer than we'd like it to be in practice.

To me, Boost review has boiled down to vibes. Do we trust the vibes that
Boost is better off with this library and do we trust that the authors are
going to stick around and evolve the library?

In my view, this library solves problems people would want Boost to solve
so I'd say I give a recommendation to ACCEPT this library.

This is a no-frills library that doesn't really have much cognitive
overhead, so reviewing it is always kind of tricky. But in these cases, I
think a fresh coat of paint just on the interface is a good start. And
also, the amount of tests is exactly what I'd expect and I think we should
remember that the lion's share of the work went into that.

- Christian