Re: [multiprecision] Getting the best performance on windows for uint128_t etc

From: Stian Zeljko Vrba (vrba_at_[hidden])
Date: 2019-07-14 09:23:32

> That's only possible with assembly level add/multiply/divide.

For the record, MSVC has compiler intrinsics for double-wide arithmetics, both signed and unsigned. For example:

https://docs.microsoft.com/en-us/cpp/intrinsics/mul128?view=vs-2019

-- Stian

________________________________
From: Boost-users <boost-users-bounces_at_[hidden]> on behalf of John Maddock via Boost-users <boost-users_at_[hidden]>
Sent: Friday, July 12, 2019 12:21:30 PM
To: degski via Boost-users
Cc: John Maddock
Subject: Re: [Boost-users] [multiprecision] Getting the best performance on windows for uint128_t etc

On 12/07/2019 09:12, degski via Boost-users wrote:
> On Fri, 12 Jul 2019 at 10:38, John Maddock via Boost-users
> <boost-users_at_[hidden] <mailto:boost-users_at_[hidden]>> wrote:
>
>     Aside: adding a native population count function might well be a
>     useful
>     addition to the library...
>
>
> Native clz/ctz (_BitScanReverse/_BitScanForward) might be useful as well.

That's done as msb/lsb (most/least significant bit).

>     The limb size is always half the width of the largest compiler
>     supported
>     integer type - this is a necessary condition to implement arithmetic
>     entirely within the language.
>
>
> This seems a high price to pay [I guess the 'within the language' is
> key here]. At some point in time [when 64-bit started to be a general
> thing] there was some info regarding this on gmplib.org
> <http://gmplib.org>, which basically stated that 64-bit limbs [on x64]
> were 4 times faster than 32-bit limbs. GMP (MPIR) does 64-bit limbs on
> Windows, no problem [but yes it's C].

That's only possible with assembly level add/multiply/divide.

Ah OK, just looked at MPIR on win64 with the mpir_gc backend, and they
do use 64-bit limbs, but rely on GNU's longlong.h for
add/subtract/multiply which appears not to use inline assembly for msvc,
but instead breaks the inputs into high/low parts and then does
schoolbook multplication.  I would expect that to be quite a bit slower
than just using 32-bit limbs in the first place, but no doubt you would
make gains on the bitwise operations, likewise if you're using an
assembly level backend.

Best, John.

>
>     If clang-win can have __int128 support enabled
>
>
> clang-cl can/will have __int128 support enabled by passing it '-Xclang
> -fforce-enable-int128', i.e. pass '-fforce-enable-int128' to clang++.
>
> degski
> --
> @realdegski
> https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-penalty-intl/
> "Anyone who believes that exponential growth can go on forever in a
> finite world is either a madman or an economist" - Kenneth E. Boulding
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
https://lists.boost.org/mailman/listinfo.cgi/boost-users