Seeking Endorsement: Boost.int128

Matt Borland via Boost <[email protected]> Tue, 28 Apr 2026 17:02:52 +0000

Newsgroups	gmane.comp.lib.boost.devel
Message-ID	<GteecmOrMT6TM71hBIJ4rSHL2Hjvc9BN6JJdVy8tZzZZwwpIHQDmyClP7O6t-tV3dPozhX7yb77JXtjeJB4pRiyry4LR-GXqPasa-CGlfcQ=@mattborland.com>

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

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)

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/

publickey - [email protected] - 0xC1382EAD.asc (application/pgp-keys, 653 B)

signature.asc (application/pgp-signature, 343 B)