I came to announce my package nint128, 128-bit integers. It is not yet 100% (the basics are done), but it is already quite usable. The intention of the package is to always try to achieve the best possible performance.
I am currently testing on amd64 and i386. I have already made some performance improvements regarding multiplication and division.
Feel free to help.
I've made some changes in nint128 to allow, when possible, to use the C extension of the GCC and CLANG compilers for 128-bit integers (__int128 and unsigned __int128) or to use VCC compiler intrinsics. This adds the possibility of optimizations that compilers have for 128-bit operations.
For more information, visit here.
Thank you for the link.
Well, I didn't use libdivide's 128÷64-bit division as a basis. For the 256÷128-bit division I used stint's div2n1n, with subtle modifications. I believe that the implementation of stint does not have the same problems.
@rockcavera ,
This is fantastic work! A while back I needed 128bit support for handling in a Decimal library. So, I wrote a miniature version but did not get very far at all.
Have you considered offering this to the standard library? That way other 3rd party libraries could use it as a common shared type.
I see the actual struct is composed of 64bit integers; which is a good way to go. Sadly though, that means the library cannot be used with a javascript target. But I suspect having a conditionally compiled 32-bit variant would not be an "easy add on" :).
For javascript I see no reason to have a 128-bit integer. A big ints option is more valid, as you are not looking for performance in javascript.
Another reason to keep 64-bit integers as a basis is to delegate to the C compiler the optimizations of these integers when used on 32-bit architectures.
I don't think it's difficult to transform the code into a 32 to 64 and then use 64 to 128. I myself transformed the code into an 8 to 16 for proof concept, so I was able to test all possibilities of addition, subtraction, multiplication and division.
About making it part of the standard library, I believe I already answered you once inside github.