Re: Seeking Endorsement: Boost.int128

Matt Borland via Boost <[email protected]> Tue, 28 Apr 2026 23:38:58 +0000

Newsgroups	gmane.comp.lib.boost.devel
Message-ID	<QMp_dbVc5ExI3IA-mqrARtekSOvHGBX_cjAjWeZGs47X5NnjHLM6fWa9DuoW5PLy3aYcQfK5CKWDE0uZEbAlbQYwQJx3Qhf_OCKnqUbcxHE=@mattborland.com>

> What is needed to use GMP mpz_powm() modular exponention on int128?
> Conversion to Boost.Multiprecision gmp_int, or directly to GMP?
> 

> Would adding mpz_powm() like function to new library make sense?
> If such int128 powm would be faster than GMP mpz_powm I would say yes.
> 


To convert to mpz_t you could do something like:

boost::int128::uint128_t val;
mpz_t z;
mpz_init(z);
uint64_t words[2] = { val.high, val.low };
mpz_import(z, 2, 1, sizeof(uint64_t), 0, 0, words);

I don't have any special bindings for easy conversions to multiprecision types.

Without measuring I will assume that a special case of a two word modular exponentiation in the library would be a good bit faster. I already have a way for 128 by 128 mul to result in a 256-bit array in the library (I use this for mul in decimal128_t). Same for the 256-bit by 128-bit reduction. I believe that GMP's small value optimization is 128-bits, so they would need to make at least one heap allocation for this operation.

I can look into this in the next few days for you.

Matt

_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/G43KWSQKKHBMQXRMHBFDHKH27BIBFJPN/

publickey - [email protected] - 0xC1382EAD.asc (application/pgp-keys, 653 B)

signature.asc (application/pgp-signature, 343 B)