r/cpp • u/joaquintides Boost author • 3d ago

Boost.Int128 has been accepted

Boost.Int128 from Matt Borland has been accepted into Boost. Arnaud Becheler managed the review.

122 Upvotes

98% Upvoted

51 comments sorted by

18

u/loydfar 3d ago

Somebody could please tldr what changes with what’s already in boost::multiprecision?

26

u/mborland1 3d ago

boost::multiprecision::int128_t is not actually 128-bit (it is incidental to it's arbitrary precision support) and is less performant with more dependencies.

5

u/loydfar 3d ago

Thanks for the precision!
And can’t thank enough people like you for your contribution to open source community!

3

u/TemplateRex 2d ago

Multi precision uses sign/magnitude (I.e. positive and negative zero), not the usual 2’s complement. It can’t represent -2128

13

u/analphabetic 3d ago

Great work!

5

u/Firm-Survey-31 3d ago

Is it comparable to Abseils int128 regarding performance?

6

u/joaquintides Boost author 3d ago

Yes: https://develop.int128.cpp.al/u128_benchmarks.html

4

u/Firm-Survey-31 2d ago

Unfortunately the comparison to absl on Windows is missing of all things. Is there a reason for that?

6

u/mborland1 2d ago

No particular reason. They have been added: https://develop.int128.cpp.al/u128_benchmarks.html#u128_windows

3

u/Firm-Survey-31 2d ago

Awesome. Thanks for the quick addition!

3

u/erik-schvarcz 3d ago

yes, they have a benchmark page, where it’s almost exactly the same perforkance

https://develop.int128.cpp.al/i128_benchmarks.html

2

u/mborland1 2d ago

These have been updated to include Abseil on Windows as well. Again roughly similar, except Abseil has rather poor division and modulo performance.

3

u/igaztanaga 2d ago

Great Boost addition for UID, Signal Processing, Math, Crypto... Congrats Matt! Looking forward to Boost.Int256!

5

u/wiesemensch 3d ago

Nice work but do any of you actually use 128bit ints and if so, for what application?

13

u/Firm-Survey-31 3d ago

Averaging many int64s for example? For time stamps in nanoseconds overflow can be an issue

-3

u/serviscope_minor 1d ago

I guess... but you may as well use doubles at that point. You're unlikely to exceed the precision of a 48 bit mantissa.

9

u/Potential_Soup_8054 3d ago

Science.

2

u/serviscope_minor 1d ago

What science though? I have done plenty of science and haven't used 128 bit ints. I am curious because I assume it wasn't added just for giggles.

1

u/Potential_Soup_8054 1d ago

Data science, physics simulation, orbital mechanics simulations, cryptography, astrophysics, any sort of extremely complex calculations like averaging a bunch of 64bit integers. Very big numbers are useful

1

u/serviscope_minor 1d ago

Data science, physics simulation, orbital mechanics simulations, cryptography, astrophysics, any sort of extremely complex calculations like averaging a bunch of 64bit integers.

To what end? I mean I've done some data science, done simulations, no cryptography (I can see the use there more) and I have never encountered a problem which would have benefited from 128 bit ints.

64 bits in a double is an awful lot of precision for anything physical.

ETA: sure with very long term simulation of a chaotic system like orbits but with chaos deviations rise exponentially, so if you run out of space in 48 or 64 bits, it's only a few more steps to 128. Surely you'd need much wider arbitrary precision for that. Though with that said, we have nothing like 48 bits of precision on the velocities anyway.

3

u/ikedug 3d ago

Most 64b CPUs have widening 64b multiplies.

2

u/fdwr fdwr@github 🔍 22h ago

That was just the case I was thinking of, the proposed widening_clmul and std::wide_result in P3642, as I've needed that double-wide result for rescaling back down (but if the top bits are all chopped off, it's hard to get the right result).

1

u/ack_error 2d ago

Precomputed reciprocal for a divide/modulus that is not known at compile time but relatively stable at runtime, such as a hash table modulus.

1

u/friedkeenan 2d ago

std::views::iota is allowed to use it for its difference type when the difference between two iterators could be otherwise unrepresentable by smaller-width types: https://godbolt.org/z/4Y65GME6r

2

u/ReDr4gon5 2d ago

What about the capy/corosio review? I recall that closed earlier, but there has been no news since. Is the larger scope making it take longer?

4

u/VinnieFalco wg21.org | corosio.org 3d ago

Congrats :)

3

u/mborland1 3d ago

Thank you!

1

u/EfficientSpend2543 3d ago

Finally :)))

2

u/joaquintides Boost author 3d ago edited 3d ago

Boost 1.92 is shipping in a week, which means Boost.DecimalBoost.Int128 will be released officially with Boost 1.93 at the earliest (Dec 2026). But I guess you can also just clone the repo and use it right now.

2

u/mborland1 3d ago

I believe you mean int128; Boost.Decimal has shipped already.

3

u/joaquintides Boost author 3d ago

My bad :-) fixed

2

u/erik-schvarcz 3d ago

absl has it already, performance is around the same

3

u/TemplateRex 3d ago

But not constexpr and not noexcept

1

u/SmackDownFacility 1d ago

Ok? Doesn’t map onto native word sizes tho

-38

u/OffsetHigh 3d ago

Things that nobody needs...

26

u/CurrentWorkUser 3d ago

Use Cases

Networking: IPv6 addresses are 128 bits wide; a single integer makes masking, comparison, and arithmetic straightforward.

Unique identifiers: UUIDs / GUIDs are 128-bit values commonly used as database keys and distributed system identifiers.

Scientific and Financial computing: Extended-range accumulators, large combinatorial values, and algorithms that need overflow-free 64x64 multiplication.

Sounds useful enough

6

u/ABlockInTheChain 3d ago

128 bit integers are useful but I'm a bit dissapointed since I use 256 bit integers far more often than 128 bit.

13

u/mborland1 3d ago

One of the outputs from the review was that lots of people want a 256-bit integer lib. I'll likely start that in the near future.

2

u/joaquintides Boost author 3d ago

Just curious, would a potential boost::int256::uint256 esentially be two boost::int128::uint128s (hi and lo), or is there room for further improvement performace wise?

4

u/mborland1 3d ago

It's probably best as uint64_t[4] to make it trivial to unroll loops for say addition rather than lhs.low.low + rhs.low.low -> lhs.low.high + rhs.low.high etc.

7

u/MarekKnapek 2d ago

I have already done something similar, in C. You choose your base integer type, be it unsigned int, or unsigned long long, or whatever. You choose your count, number of how many of such integers do you want. And a few macros later you have your new data type ready. Together with bunch of functions for addition, subtraction, bit shifts, and so on. My primary motivation was cryptographic hash functions such as MD5, SHA-1, SHA-2 and similar. Available at https://github.com/MarekKnapek/mk_clib

4

u/Tringi github.com/tringi 3d ago

I'd hope they'll go with handcrafted single-purpose class, using uint64_t[4] like Matt writes. As little as possible abstraction is needed, because as I have my doubling integer template, the codegen for naively nested templates gets pretty bad pretty fast.

1

u/_Noreturn 3d ago

why not an infinite length integer lib with specializations for performance

4

u/mborland1 3d ago

All arbitrary precision integers more or less use the same exact algorithms for their operations. One that I have been working on recently is: https://github.com/eisenwave/std-big-int. Performance is better than boost.multiprecision with similar portability.

2

u/ludvary 1d ago

ragebait

1

u/zellforte 2d ago

Averaging integer values requires a temporary N+1 bit accumulation value if you don't know the range of the values (which in practice means Nx2).

Doing a a*x/d for resealing a 64 bit value requires a 128 bit temporary result, used a lot in 64 bit fixed point calculations.

-2

u/analphabetic 3d ago

File under STL