On Tue, Apr 28, 2026 at 5:05 PM Matt Borland via Boost < boost@lists.boost.org> 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-si...
[4] https://pdimov.github.io/boostdep-report/develop/module-weights.html _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/FTHD7S6D...