Re: Decimal: Formal review begins

From: Matt Borland (matt_at_[hidden])
Date: 2025-01-20 22:31:03

> 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.
> 

My concern is the reference of portable library vs a fully vertically integrated one. I would expect a vendor library compiled with the same vendors compiler on the same vendors hardware to be the fastest available. What about anyone on non-x64 machines? Is there room for performance improvement in the library? For sure. Will we ever be fastest on x64? Probably not. Are we the fastest on an M1 Mac? To my knowledge yes.

> 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.
> 

Yes, we seamlessly provide everything you'd expect in a C++ library today. Ivan Matek has even been submitting issues using std::print. That's pretty modern support.

> 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
> 

> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost