Re: Seeking Endorsement: Boost.int128

  > I am seeking endorsement for review of my> library int128 [1]. 
I endorse (u)int128.
It should be a library, on its own, and beseparate from Boost.Core.
Its purpose is to provide (u)int128_t forall platforms, and is seamless if theplatform already has 128.
It is not a Multiprecision type. In fact,it much more closely resembles (u)int64_t(which is also kind of new in my world)
Clients of Boost.Multiprecision willhopefully not confuse this with a synthesizedMultiprecision type. If confusion exists, it caneasily be cleared up in ensuing chats or issues.
This type (these types) is/are intendedto provide a native-like type.
- Christopher

    On Tuesday, April 28, 2026 at 07:04:28 PM GMT+2, 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].

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/ 
  
_______________________________________________
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/3BFMFZJT6OB3GYHZDYHRLLOAYBXFW73N/