Re: mpz reuse test takes too much time

[Vincent Lefevre]

On 2016-09-28 16:24:15 +0200, Torbjörn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   But there may have been a temporary problem, as I now get:
>   
>   ./reuse  27.56s user 0.15s system 100% cpu 27.698 total
>   
> That's more in the expected range.  Amd bulldozers are not GMP speed
> demons, with their 1/4 mul throughput, but they are not that slow.

This seems consistent with the 4200.19 bogomips given by /proc/cpuinfo.

As a comparison, with a loaded Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
(5588.28 bogomips) machine, I get 18.58s (8.50s if not loaded).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz reuse test takes too much time

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> We need to factor in the size-dependent algorithms too.  While most
> algorithm choices are made at the mpn level, we need to ensure that mpz
> makes the correct overlap assumptions wrt mpn.

Hmm, so you're saying that if some mpn function doesn't allow overlap,
but happens to allow it for small sizes (or is mpz calls a different,
more liberal, function for small sizes), then some mpz bugs will not be
visible when using small operands. It would be nice if we could get good
coverage for that, without using large operands for all reuse tests.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz reuse test takes too much time

[Niels Möller]

ni...@lysator.liu.se (Niels Möller) writes:

> and for a five-operand
> function like gcdext, I can't easily get the correct count

Actually, in the case of gcdext, there are three result arguments, which
mustn't overlap with each other.

So there are only 16 cases of valid overlap when all operands are
provided, and 9 cases of valid overlap when the t argument is NULL.

> Then we shouldn't need more than a few 10 calls cover all cases, and
> we shouldn't need very large operands.

Hmm, that's perhaps too pessimistic. Since many of the 160 mpz functions
have only one or two mpz arguments, average number of cases per function
is likely < 10. And then we should need < 1 calls total, which I
think is on the same order as several other tests.

Am I missing something?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz reuse test takes too much time

[Torbjörn Granlund]

Vincent Lefevre  writes:

  But there may have been a temporary problem, as I now get:
  
  ./reuse  27.56s user 0.15s system 100% cpu 27.698 total
  
That's more in the expected range.  Amd bulldozers are not GMP speed
demons, with their 1/4 mul throughput, but they are not that slow.

  But note that since "reuse" is much slower than the other tests,
  one doesn't benefit much from the parallelization of the tests.

Indeed.  I don't lose too much sleep over that, and splitting up
tests/mpz/reuse,c into several tests would seem to have several
disadvantages.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz reuse test takes too much time

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> It is supposed to take a lot of time, as it tests all mpz functions for
> correct operand overlap.

There seem to be 160 mpz functions (checking the libgmp which is installed on my
office machine).

For a two-operand function, there are two cases, aa and ab (where my
notation is that distinct letters are distinct locations).

For a three-operand function, there are 5 cases, aaa, aab,
aba, abb, abc.

For a four-operand function, we get 14 distinct cases (and I'm losing
confidence that I get the combinatorics right), and for a five-operand
function like gcdext, I can't easily get the correct count but it must
be < 5^4 = 625. Do we have any function with more than 5 arguments?

Then we shouldn't need more than a few 10 calls cover all cases, and
we shouldn't need very large operands. Is 10--40 seconds reasonable for
that?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs