[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: |
| 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. |
| Comment by Luke Bhan (Inactive) [ 10/Aug/21 ] |
| 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. I'd like to minimize our dependence on Abseil as they are loose with standards compliance. |
| 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/ |