Niels,
> From: ni...@lysator.liu.se (Niels Möller)
> Cc: gmp-devel@gmplib.org, raphael.rieu-he...@lri.fr
> Date: Wed, 25 Apr 2018 22:22:41 +0200
> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix)
>
> ni...@lysator.liu.se (Niels Möller) writes:
>
> > paul zimmermann writes:
ni...@lysator.liu.se (Niels Möller) writes:
> paul zimmermann writes:
>
>> together with Raphaël Rieu-Hleft (in cc), we believe we have found some dead
>> code in
>> mpn/generic/div_q.c around lines 173-182:
>>
>> else if (UNLIKELY (qh != 0))
>> {
>> /* This h
t...@gmplib.org (Torbjörn Granlund) writes:
> ni...@lysator.liu.se (Niels Möller) writes:
>
> For n x 20, n pretty large, what strategy does mpn_mul use? I would
> expect repeated toom32, but maybe that gives too much overhed. It seems
> we don't have any MUL_TOOM32_TO_BASECASE threshold?
>
ni...@lysator.liu.se (Niels Möller) writes:
For n x 20, n pretty large, what strategy does mpn_mul use? I would
expect repeated toom32, but maybe that gives too much overhed. It seems
we don't have any MUL_TOOM32_TO_BASECASE threshold?
I believe this is the logic triggered in this case:
On 2018-04-25 11:30:28 +0200, Torbjorn Granlund wrote:
> paul zimmermann writes:
>
> Now MPF is faster than MPFR for all 100d operations, for 1000d and 1d
> div. You have done a great work in GMP 6!
>
> The differences there are marginal.
Moreover, the new timings have been done on an A
t...@gmplib.org (Torbjörn Granlund) writes:
> More embarrassments. :-)
>
> I ran some timing tests without my proposed change and with the squqring
> exception code still there. Please consider the following two
> measurements for doing n x 19 limb (first table) and n x 20 limb
> multiplication.
More embarrassments. :-)
I ran some timing tests without my proposed change and with the squqring
exception code still there. Please consider the following two
measurements for doing n x 19 limb (first table) and n x 20 limb
multiplication.
MUL_TOOM22_THREASHLD is 20 for this machine (compiled
Dear Torbjörn,
> I am surprised that there are non-marginal differences for larger
> operations. Don't we all use mpn? Bookkeeping should be the only
> difference.
since 2004 we did implement in MPFR "short" product/square/division,
which compute an approximation of the upper n limbs of
paul zimmermann writes:
Now MPF is faster than MPFR for all 100d operations, for 1000d and 1d
div. You have done a great work in GMP 6!
The differences there are marginal.
I am surprised that there are non-marginal differences for larger
operations. Don't we all use mpn? Bookkeeping s
"Marco Bodrato" writes:
Changes between GMP version 4.3.X and 5.0.0
[...]
FEATURES
[...]
* New mpn functions: mpn_sqr, mpn_and_n, mpn_ior_n, mpn_xor_n, mpn_nand_n,
[...]
MISC
* The mpn_mul function should no longer be used for squaring,
instead use the new mpn_sqr.
Dear GMP developers,
I have updated my comparison of multiple-precision floating-point software.
The old page was comparing MPF from GMP 5.0.2 with (among others) MPFR 3.1.2:
http://www.mpfr.org/mpfr-3.1.2/timings.html
Here, MPF was only faster than MPFR for 100d mul and sqr, and 1000d di
Ciao,
Il Mar, 24 Aprile 2018 2:34 pm, Victor Shoup ha scritto:
> Also: when exactly was mpn_sqr added to the public interface?
https://gmplib.org/list-archives/gmp-announce/2010-January/24.html
Changes between GMP version 4.3.X and 5.0.0
[...]
FEATURES
[...]
* New mpn functions: mpn_sqr,
12 matches
Mail list logo
