Re: Seeking Endorsement: Boost.int128

On Tue, Apr 28, 2026 at 5:05 PM Matt Borland via Boost <
[email protected]> 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].
>

Which Multiprecision backend did you use for the benchmarks (cpp, gmp, tom)?


>
> 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].
>
> Should this go in Core (or other existing lib)?
>
> I talked with Peter about this a while back, but int128 was already
> getting too big at the time. Now int128's include/ directory has a higher
> sloccount than core's, so it makes even less sense. I would rather it not
> go into Multiprecision, as int128 would have a module weight of up to 5
> (optional dependencies), whereas Multiprecision has a module weight of 25
> [4]. The design is fundamentally different than the types used in
> Multiprecision as well (All types are backends into a master template
> called number for compatibility)
>
>
I appreciate the detailed explanations here. However, I can imagine users
of Multiprecision might grumble about having to use two different libraries
to get, for example, extended float and int28. I would emphasize the
benefits in the docs to try to mitigate this.


> Why does the library have a low number of stars?
>
> This library started life as the backend for Boost.Decimal since we needed
> a cross platform 128-bit integer for the representation of decimal128_t as
> well as to perform fundamental operations with decimal64_t. You can still
> find a int128/ folder in Decimal that will be removed if this lib is
> accepted (it's a vendored version of the library now). I find these types
> useful for my own purposes, so I expect others will too.
>
> Please let me know if you have any questions as you take a look at the
> library.
>
> Thanks for your time,
> Matt
>
> [1] https://github.com/cppalliance/int128
>
> [2] https://develop.int128.cpp.al/u128_benchmarks.html
>
> [3]
> https://stackoverflow.com/questions/41876253/boostmultiprecisionuint128-t-sizeof-is-24
>
> [4] https://pdimov.github.io/boostdep-report/develop/module-weights.html
> _______________________________________________
> 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/FTHD7S6DHZFHRKVDFUVN7QOANA7P4E5U/
>
_______________________________________________
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/JD4ZUSID52BSXN6RTLWE4CJBOS3PZ45B/