Re: My review of Decimal

From: Ivan Matek (libbooze_at_[hidden])
Date: 2025-01-21 14:59:32

On Tue, Jan 21, 2025 at 2:52 PM Glen Fernandes <glen.fernandes_at_[hidden]>
wrote:

> I would like to have this PDF on the Boost site somewhere,  if there are
> no objections. I can take care of that and reply with the link.
>
> When people revisit past reviews in the Boost archives:
> https://lists.boost.org/Archives/boost/2025/01/date.php
>

If you could do that it would be appreciated although I guess that for at
least next few years my drive link is gonna stay alive.

On Tue, Jan 21, 2025 at 3:14 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Matt Borland wrote:
> > Taking decimal types by reference instead of by value - fundamentally the
> > decimalXX types are std::uint32_t, std::uint64_t, and struct { uint64_t
> hi,
> > uint64_t lo }. I don't think you'll see any performance improvements with
> > those.
>
> Trivially copyable types up to 2*uint64_t in size are passed in
> registers (on non-Windows x86-64), so pass by reference will be a
> performance regression, probably a significant one.
>

If you have time I suggest to read the PDF. I know your time is valuable,
but I just think it is faster if we are on same page.
In this particular case I tried to be pretty clear in document about this.
I was not talking about small types. Also not all functions take 1
argument, in PDF I explicitly used copysign as example.
And it *may* be possible that even if decimal128 pass by value is faster
decimal128_fast pass by value is not.

On Tue, Jan 21, 2025 at 3:36 PM John Maddock via Boost <
boost_at_[hidden]> wrote:

> It may be worth the experiment, but I'd be surprised if adding a level
> of indirection is of benefit over passing arguments by value in a couple
> of registers: possibly there may be benefit for functions accepting many
> arguments, but I'm assuming there aren't too many of those?
>
> John.

I am a man of data. :) If there are realistic benchmarks saying passing
"large" decimals is fine I will believe them. Till then I believe it is not
optimal.
Also library seems to prefer to pass by reference in certain cases, e.g.
contrast this 2 "opposite" functions and their argument types

constexpr auto isfinite(decimal128_fast val) noexcept -> bool
{
    #ifndef BOOST_DECIMAL_FAST_MATH
    return val.significand_.high < detail::d128_fast_inf_high_bits;
    #else
    static_cast<void>(val);
    return true;
    #endif
}

constexpr auto not_finite(const decimal128_fast& val) noexcept -> bool
{
    #ifndef BOOST_DECIMAL_FAST_MATH
    return val.significand_.high >= detail::d128_fast_inf_high_bits;
    #else
    static_cast<void>(val);
    return false;
    #endif
}