[SERVER-59139] Refactor of boost multiprecision 128 to abseil Created: 05/Aug/21  Updated: 29/Oct/23  Resolved: 16/Aug/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Luke Bhan (Inactive) Assignee: Luke Bhan (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2021-08-09, Execution Team 2021-08-23
Participants:

 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 12/Aug/21 ]

Author:

{'name': 'lukebhan', 'email': 'luke.bhan@vanderbilt.edu', 'username': 'lukebhan'}

Message: SERVER-59139 refactor to use abseil for int128
Branch: master
https://github.com/mongodb/mongo/commit/691d4c3db4b13c60a1c4cd3e210de4c983f186b3

Comment by Billy Donahue [ 10/Aug/21 ]

Yes I agree we shouldn't write our own. The absl library will use a native 128-bit integer extension if it exists, which is nice. I just wish they didn't incorrectly mess with std::numeric_limits. And the boost::multiprecision flaw was surprising to me.

Comment by Luke Bhan (Inactive) [ 10/Aug/21 ]

https://mongodbcr.appspot.com/822640002/

Comment by Luke Bhan (Inactive) [ 10/Aug/21 ]

I see your point. Currently, I wrote the CR with absl::Int128Max(), but I see how down the line it can be confusing. However, Id rather then use them over writing our own library and I think henrik.edin would agree. 

Comment by Billy Donahue [ 10/Aug/21 ]

I'm not sure what you mean by "true 128 bits", but I see that boost's docs have:

"The type uses a sign-magnitude representation internally, so type int128_t has 128-bits of precision plus an extra sign bit. In this respect the behaviour of these types differs from fundamental (built-in) 2's complement types. In might be tempting to use a 127-bit type instead, and indeed this does work, but behaviour is still slightly different from a 2's complement fundamental (built-in) type as the minimum and maximum values are identical (apart from the sign), where as they differ by one for a true 2's complement type. That said it should be noted that there's no requirement for fundamental_types to be 2's complement either - it's simply that this is the most common format by far."

Which sounds hard to work with. Not 2's complement.
It's regrettable that we have to take a further dependence on absl though . But that's life.
Thanks for your response.

I'd like to minimize our dependence on Abseil as they are loose with standards compliance.
For example, they specialize std::numeric_limits<absl::int128_t> and this is not appropriate to do according to the standard, as absl::uint128 is not an "arithmetic type" according to C++'s definition of that term.

https://github.com/mongodb/mongo/blob/master/src/third_party/abseil-cpp-master/abseil-cpp/absl/numeric/int128.h#L255

Comment by Luke Bhan (Inactive) [ 10/Aug/21 ]

Actually yes. We originally used boost 128; however, Boost int128 stores an int as a true 128 bits instead of 127+signed which makes casting quite horrendous. (The zigzag as is would fail miserably). There is actually an open ticket to refactor which 822600001 is rebased on. (https://mongodbcr.appspot.com/822600001/)

Comment by Billy Donahue [ 10/Aug/21 ]

Re: https://mongodbcr.appspot.com/822600001/
Is absl::int128 better than boost::multiprecision::int128?

Generated at Thu Feb 08 05:46:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.