Re: [int128] Some thoughts

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3477751347078605319==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="------03f30d942c1d04fae9eb50aeb73566d30381879484f2340b90f389511aead333";
 charset=utf-8

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------03f30d942c1d04fae9eb50aeb73566d30381879484f2340b90f389511aead333
Content-Type: multipart/mixed;boundary=---------------------a73b6d12a19731b152b708d9f189f17a

-----------------------a73b6d12a19731b152b708d9f189f17a
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8


> Your benchmark results were encouraging and might tempt me to consider u=
sing
> this in the future as a result. I would remark I see the comparison with
> the abseil 128 numbers interesting WRT addition and signed vs unsigned.
> It looks like your implementation is optimised for unsigned whereas as
> abseil favours signed? FWIW I'd see more value in optimising
> mathematical operations for signed integers. If you are using unsigned
> ints for that you probably have a design issue.
> =



On almost all of the 64-bit platforms (s390x being the outlier), the opera=
tions shown in the benchmarks are just delegating to the built-in __int128=
. On 32-bit platforms the operations are performed in the unsigned domain =
with algorithms such as Knuth using a 32-bit limb size. =



> In looking over the code (briefly) I got to wondering if you could apply
> similar principles to a 256 bit type. For us we always need 128 and 256
> bit integer types (we do a lot of EVM based work which uses 256 bit
> ints). Currently we are forced to use boost.multiprecision for 256 bit
> ints which has all the issues you mention and would be a very obvious
> replacement for us. Like many who need int128 today, they already have a
> workaround, but nothing useful exists for 256 bit numbers which are very
> common in the crypto and blockchain world. Would it be challenging to
> develop a similar library for 256 bit support given your experience of
> developing this 128 library?

Developing a separate int256 lib would not be a huge jump. At that size we=
 can still use the schoolbook algorithms out of int128. Much like how int1=
28 started life as the backend of Boost.Decimal, there is the better part =
of a u256 inside of Decimal already. =



Have you ever used Boost.Multiprecision's standalone mode? It can help tam=
e the weight of the package. The only dependency in that mode is Boost.Con=
fig, which we ship as a bundle on the releases tab of the Github page.

Thank you for your thoughts and potential review.

Matt
-----------------------a73b6d12a19731b152b708d9f189f17a
Content-Type: application/pgp-keys; filename="publickey - [email protected] - 0xC1382EAD.asc"; name="publickey - [email protected] - 0xC1382EAD.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - [email protected] - 0xC1382EAD.asc"; name="publickey - [email protected] - 0xC1382EAD.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWDJ3Z2RCWUpLd1lCQkFI
YVJ3OEJBUWRBVUhPaDBLcGJaQ3N6aGR2S3p0V2o0QzZGUjFvek1CUUUKd2FCaTNtMlBKSExOSzIx
aGRIUkFiV0YwZEdKdmNteGhibVF1WTI5dElEeHRZWFIwUUcxaGRIUmliM0pzCllXNWtMbU52YlQ3
Q2p3UVFGZ29BSUFVQ1gyd2dkQVlMQ1FjSUF3SUVGUWdLQWdRV0FnRUFBaGtCQWhzRApBaDRCQUNF
SkVGbUJXbFZDRmFXbEZpRUV3VGd1clRjb0h3YmRTYklzV1lGYVZVSVZwYVZXdXdFQTc3cm0KT0E0
VEI2WHhlNnE4Z0k0MmJFSUNNaE15WktTTWNha3ozOS9kallrQkFNSk9HK0lHUUMvZDBuM2RzbDEw
CktnL294WDg4a0ZPMW9QS240L1hXK1RvQnpqZ0VYMndnZEJJS0t3WUJCQUdYVlFFRkFRRUhRT3Nt
bzZ3UgpVdVhSQXZGSWlxbVFrellyUHl2S1lLbmEyejRadG1uVFFNa01Bd0VJQjhKNEJCZ1dDQUFK
QlFKZmJDQjAKQWhzTUFDRUpFRm1CV2xWQ0ZhV2xGaUVFd1RndXJUY29Id2JkU2JJc1dZRmFWVUlW
cGFXVUp3RUE1RzBjClpSbkc1V0dORXJJK3k5MGlRclR2MDJpNEl2aHY3dHdvRmNMRC96d0Evakt5
cHcrdmVoRTk5bUVqMS91SQpFa29ERmxOelFacU5sZGJqUmNQeUk1VUgKPTQ2MlMKLS0tLS1FTkQg
UEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQo=
-----------------------a73b6d12a19731b152b708d9f189f17a--

--------03f30d942c1d04fae9eb50aeb73566d30381879484f2340b90f389511aead333
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmpnUKwJEFmBWlVCFaWlRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmcjaReIXhbTRuEWQf47vuAapeSVPSBwPvz6e7Mr
T3JSXhYhBME4Lq03KB8G3UmyLFmBWlVCFaWlAAA05gEA+1PcuPimA3YpdGXZ
xkU1cUBNuxB2Zply2+1EGRVerz4BAIksVgVixW9rsM/EFJXysMclvANmApJz
YlhRjfrreJwO
=vXRM
-----END PGP SIGNATURE-----


--------03f30d942c1d04fae9eb50aeb73566d30381879484f2340b90f389511aead333--


--===============3477751347078605319==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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/KLA63LZ7GW7HD2DGYSFZWLM5RKOCBKRI/ 

--===============3477751347078605319==--