Re: Seeking Endorsement: Boost.int128

On 2026-04-28 19:02, Matt Borland via Boost wrote:
> Dear All,
> 
> I am seeking endorsement for review of my library int128 [1]. The
> library requires only C++14, is header only, and has no mandatory
> dependencies. What does int128 provide? Two portable and performant
> types: a 128-bit signed integer and a 128-bit unsigned integer, as
> well as a standard library for them. The performance of these types
> have been tuned and tested on a variety of architectures to include:
> x64, x32, s390x, ARM64, ARM32, PPC64LE. Both of the types and most of
> their library functions also work inside CUDA kernels. Benchmarks
> against Boost.Multiprecision, Absl, MSVC's software 128-bit integers,
> and built-ins, are available [2].
> 
> A couple of questions that I anticipate:
> 
> Why do we need this if we already have Boost.Multiprecision?
> 
> 
> An old compliant against Boost.Multiprecision is that the 128-bit
> integer types are not 16 bytes [3]. The 128-bit integer types are also
> incident to the arbitrary precision type rather than a dedicated
> implementation. This allows int128 to improve performance in places
> that Multiprecision can't or shouldn't which is reflected in the
> benchmarks [2].
> 
It would be good to have a more performant 128bit integer type.

What is needed to use GMP mpz_powm() modular exponention on int128?
Conversion to Boost.Multiprecision gmp_int, or directly to GMP?

Would adding mpz_powm() like function to new library make sense?
If such int128 powm would be faster than GMP mpz_powm I would say yes.

Regards,

Hermann.
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/UZMCF72SCM5BZ2LXZBUGFB7JSVDQ32FP/