Hi Matt, Thanks for writing this library - it looks very useful and certainly fills a hole. This is not a review, just some thoughts from a quick look at the docs and source code. From the docs all your use cases are relevant to us, and in particular the third for financial computing. We do exactly that. Currently we build on gcc and use `__int128` with a few workarounds. In general that's been fine. Replacing with `int128` would likely bring us little value at this stage but certainly I could see good value for any new projects and especially for those looking for portability. 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. 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? As I said I see value in Int128, but it is more a nice-to-have for us since we have something lightweight already (__int128) but would dearly love to see a solid Int256 library that perhaps compliments Int128. If I get more time later in the week I might try and do a proper review. Jamie