Is there a way to make uint128_t really 128 bit?

[pps83]

Not sure if it was raised by others, but is there a way to actually make uint128_t to be 128 bit? For some reason, I have mental rejection from using boost::multiprecision::uint128_t / int128_t because it's not true 128 bit int.
I just saw explanation why boost::multiprecision::uint128_t sizeof is 24 and it might make sense for some huge numbers, but not sure if it makes sense for 128 bit. To me it feels like uint64_t that was only usable for 60 bits with some bits used to track what 16-bit num is in use, or, as if uint64_t was actually 80bit in size. Both aren't OK imo if there was no way to opt out from it. Also, instead of using some var, to keep track of what's set, obviously, it would be better to comply test the number itself (if it's meant for checking zero or not).
IMO, it would be better if uint128_t/int128_t from boost at least generated optimal code for regular math operations. Even __msvc_int128.hpp is more than 2x faster in my tests for basic calculations.

[mborland]

@ckormanyos and I were talking about this recently. We have an optimized u128 that we use in the backend of a different library. Should this go into multi precision or a separate library? I lean towards the latter since 128 bit ints are more broadly used than arbitrary precision arithmetic.

[pps83]

We have an optimized u128 that we use in the backend of a different library

are you referring to https://github.com/ckormanyos/wide-integer ? I looked into the code and decided to skip it. Only intx seemed like good to test.

As a side note, I compared multiple libs and it looks like __msvc_int128.hpp is overall does really well compared to all others. The only case where it's loses is when built-in __int128_t/__uint128_t could be used (and it seems that clang has some issues supporting them on windows). abseil-uint128_t, for example, is extremely slow on ms compiler for some reason.

I lean towards the latter since 128 bit ints are more broadly used than arbitrary precision arithmetic.

In my case, the only reason I touched multiprecision was to get some 128bit int math done instead of wasting time doing it all myself. Apparently, it's not exactly what I think it was. Perhaps, most of the users also come to take simplest stuff like me: 128 int/uint

[mborland]

We have an optimized u128 that we use in the backend of a different library

are you referring to https://github.com/ckormanyos/wide-integer ? I looked into the code and decided to skip it. Only intx seemed like good to test.

No, it's part of a decimal floating point library. This issue and linked PR can be found here: cppalliance/decimal#885. I'll have to check against __msvc_int128.hpp.

[pps83]

How would mp::int128_t convert to mp::uint128_t if I cast from one to the other? Would it do arithmetic shift magic to preserve sign bit?

void test(mp::int128_t n)
{
    mp::uint128_t u = (mp::uint128_t)n;
    mp::int128_t i = (mp::int128_t)u;
    assert(n == i);   
}

[ckormanyos]

Hi @pps83 I have noted that Matt (@mborland) has actually created cppalliance/int128.

One of the purposes of this library (in addition to dependency-free raw speed) is to have a fixed-width 128-bit signed/unsigned integral representation.

I do not believe that Boost.Multiprecision will evolve in the direction of your original query. But perhaps this potential new library (which does exactly what you queried) is what you seek?

Cc: @mborland and @jzmaddock

[pps83]

From the description it does look like a good lib for that as it tries to do only this part.

So far, lib-only code seems to be best from msft.

For my own use I have this:

#pragma once
#if defined(__SIZEOF_INT128__) && (!defined(_MSC_VER) || defined(__INTEL_LLVM_COMPILER))
typedef __int128_t int128_t;
typedef __uint128_t uint128_t;
#elif defined(_MSC_VER)
#include <__msvc_int128.hpp>
typedef std::_Signed128 int128_t;
typedef std::_Unsigned128 uint128_t;
#else
#include <boost/multiprecision/cpp_int.hpp>
typedef boost::multiprecision::int128_t int128_t; // 196 bit
typedef boost::multiprecision::uint128_t uint128_t; // 196 bit
#endif

and then I do all kinds of 128bit math. In my tests/benchmarks, when I could use clang's built-in 128bit math vs using __msvc_int128.hpp with clang the results were that the ms code behaved identical or even better in some cases (unlike all other libraries that I tried).
Do things like gcd/lcm work with it?

[ckormanyos]

Yes Multiprecision integral types have a small selection of number-theoretical functions including gcd, lcm and miller_rabin.

[mborland]

From the description it does look like a good lib for that as it tries to do only this part.

So far, lib-only code seems to be best from msft.

For my own use I have this:

#pragma once
#if defined(__SIZEOF_INT128__) && (!defined(_MSC_VER) || defined(__INTEL_LLVM_COMPILER))
typedef __int128_t int128_t;
typedef __uint128_t uint128_t;
#elif defined(_MSC_VER)
#include <__msvc_int128.hpp>
typedef std::_Signed128 int128_t;
typedef std::_Unsigned128 uint128_t;
#else
#include <boost/multiprecision/cpp_int.hpp>
typedef boost::multiprecision::int128_t int128_t; // 196 bit
typedef boost::multiprecision::uint128_t uint128_t; // 196 bit
#endif

and then I do all kinds of 128bit math. In my tests/benchmarks, when I could use clang's built-in 128bit math vs using __msvc_int128.hpp with clang the results were that the ms code behaved identical or even better in some cases (unlike all other libraries that I tried). Do things like gcd/lcm work with it?

Can you share your tests/benchmarks?

Relative to __msvc_int128 the linked lib is at parity or better on MSVC x64 with basic operations:

https://github.com/cppalliance/int128/blob/develop/doc/img/u128_graphs/windows/x64_relative_performance.png

[pps83]

Can you share your tests/benchmarks?

I had a local change in my code for evaluation/test, didn't check it in and lost. I wanted to check different libs for different cases that I use in my code (gcd, mulhi (64 high bits of 64x64 multiplication), regular multiplication by 32, 64 bit, 128/64 division etc). I used msvc, clang-cl, clang, gcc on windows/linux in 32/64 bits. __msvc_int128 is only usable on windows (msvc/clang-cl) and it did surprisingly well compared to others (and even vs linux when I tested same hw with clang/gcc with their __int128 types on x64).
I think I still have to use boost/mutiprecission because of gcd or 32bit builds. Perhaps, I can replace it all with cppalliance/int128.

[mborland]

No worries. I opened an issue to add gcd and lcm to int128. I have to figure out why my graphs don't show up in the docs, but you can see them all here. The relative is builtin, int128, and boost::multiprecision::(u)int128_t

[ckormanyos]

You could use wide-integer temporarily and transition to Matt's library later. Matt's library will be a better fit in the long run since it is tuned for 128

[jzmaddock]

Something I always left the door open for in mutiprecision, but never got around to, was to support something other than signed-magnitude in cpp_int - specifically 2's complement. The latter would have the advantage of being "packed" so 128-bits for a 128-bit integer, but would lack the limb-count so loose efficiency for large sizes (but almost certainly gain a lot at smaller sizes). Perhaps it's time to see if we can appropriate Matt's code for that use case...

[ckormanyos]

Oh that's a good idea. Just integrate Matt's code for 128 into Multiprecision. I can help with that, tests and whatnot.

[ckormanyos]

And we would need the eval_whatever functions.