Your benchmark results were encouraging and might tempt me to consider using this in the future as a result. I would remark I see the comparison with the abseil 128 numbers interesting WRT addition and signed vs unsigned. It looks like your implementation is optimised for unsigned whereas as abseil favours signed? FWIW I'd see more value in optimising mathematical operations for signed integers. If you are using unsigned ints for that you probably have a design issue.
On almost all of the 64-bit platforms (s390x being the outlier), the operations shown in the benchmarks are just delegating to the built-in __int128. On 32-bit platforms the operations are performed in the unsigned domain with algorithms such as Knuth using a 32-bit limb size.
In looking over the code (briefly) I got to wondering if you could apply similar principles to a 256 bit type. For us we always need 128 and 256 bit integer types (we do a lot of EVM based work which uses 256 bit ints). Currently we are forced to use boost.multiprecision for 256 bit ints which has all the issues you mention and would be a very obvious replacement for us. Like many who need int128 today, they already have a workaround, but nothing useful exists for 256 bit numbers which are very common in the crypto and blockchain world. Would it be challenging to develop a similar library for 256 bit support given your experience of developing this 128 library?
Developing a separate int256 lib would not be a huge jump. At that size we can still use the schoolbook algorithms out of int128. Much like how int128 started life as the backend of Boost.Decimal, there is the better part of a u256 inside of Decimal already. Have you ever used Boost.Multiprecision's standalone mode? It can help tame the weight of the package. The only dependency in that mode is Boost.Config, which we ship as a bundle on the releases tab of the Github page. Thank you for your thoughts and potential review. Matt