Re: mpz reuse test takes too much time

[Torbjörn Granlund]

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

  t...@gmplib.org (Torbjörn Granlund) writes:
  
  > Please check that reuse.c whacks gcdext appropriately.
  
  It doesn't check the cases where both input operands overlap some output
  operands, e.g.,
  
  mpz_gcdext (res1, res2, res3, res1, res3);
  
  or
  
  mpz_gcdext (res1, res2, res3, res2, res2);
  
  Should it do that, or is it enough that the reuse tests overlap one
  operand at a time? Doing all combinations everywhere does blow up the
  number of tests a bit.
  
Let's make the test slower as a reaction to Vincent's complaint!  :-)

Seriously, I think we should exercise all combinations.

-- 
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:

> Please check that reuse.c whacks gcdext appropriately.

It doesn't check the cases where both input operands overlap some output
operands, e.g.,

  mpz_gcdext (res1, res2, res3, res1, res3);

or

  mpz_gcdext (res1, res2, res3, res2, res2);

Should it do that, or is it enough that the reuse tests overlap one
operand at a time? Doing all combinations everywhere does blow up the
number of tests a bit.

/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

[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

[Torbjörn Granlund]

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

  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.
  
Please check that reuse.c whacks gcdext appropriately.

-- 
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

[Vincent Lefevre]

On 2016-09-28 15:11:28 +0200, Torbjörn Granlund wrote:
> Vincent Lefevre  writes:
>   I just did "./configure" and "make" and "make check", and
>   noticed that the "reuse" test took around 110 seconds. All
>   the other tests are much faster.
>   
> It makes no sense that it takes 110 seconds.  Your machine must be in
> bad health.  Perhaps it has problems with CPU temp and is downclocked?

I had checked with /proc/cpuinfo, and ~ 2100 MHz was the reported
frequency.

But there may have been a temporary problem, as I now get:

./reuse  27.56s user 0.15s system 100% cpu 27.698 total

(and contrary to the previous test, where the machine was not loaded,
the machine is currently fully loaded, so that the 27.56s has been
obtained on a core shared with another process, i.e. it could be
around 15s if the machine were not loaded).

Here are the details of the timings for the mpz tests:

fraise:...p-6.1.1/tests/mpz> for i in *(*); eval time ./$i
./bit  0.13s user 0.02s system 93% cpu 0.159 total
./convert  2.14s user 0.02s system 99% cpu 2.162 total
./dive  1.30s user 0.02s system 99% cpu 1.331 total
./dive_ui  0.35s user 0.02s system 98% cpu 0.379 total
./io  0.06s user 0.08s system 93% cpu 0.150 total
./logic  0.16s user 0.03s system 94% cpu 0.200 total
./reuse  27.56s user 0.15s system 100% cpu 27.698 total
./t-addsub  0.08s user 0.02s system 80% cpu 0.120 total
./t-aorsmul  0.14s user 0.01s system 89% cpu 0.161 total
./t-bin  0.04s user 0.00s system 69% cpu 0.057 total
./t-cdiv_ui  0.01s user 0.02s system 66% cpu 0.042 total
./t-cmp  0.00s user 0.01s system 39% cpu 0.031 total
./t-cmp_d  0.01s user 0.00s system 47% cpu 0.025 total
./t-cmp_si  0.01s user 0.00s system 43% cpu 0.028 total
./t-cong  0.34s user 0.01s system 94% cpu 0.375 total
./t-cong_2exp  0.01s user 0.02s system 72% cpu 0.039 total
./t-div_2exp  0.00s user 0.02s system 70% cpu 0.028 total
./t-divis  0.58s user 0.01s system 96% cpu 0.610 total
./t-divis_2exp  0.00s user 0.01s system 46% cpu 0.026 total
./t-export  0.00s user 0.01s system 49% cpu 0.024 total
./t-fac_ui  0.54s user 0.04s system 97% cpu 0.586 total
./t-fdiv  0.32s user 0.01s system 95% cpu 0.339 total
./t-fdiv_ui  0.01s user 0.02s system 64% cpu 0.037 total
./t-fib_ui  0.03s user 0.01s system 75% cpu 0.053 total
./t-fits  0.00s user 0.01s system 46% cpu 0.026 total
./t-gcd  6.43s user 0.02s system 99% cpu 6.458 total
./t-gcd_ui  0.00s user 0.01s system 53% cpu 0.030 total
./t-get_d  0.00s user 0.01s system 47% cpu 0.034 total
./t-get_d_2exp  0.00s user 0.01s system 44% cpu 0.036 total
./t-get_si  0.00s user 0.02s system 77% cpu 0.026 total
./t-hamdist  0.02s user 0.02s system 83% cpu 0.053 total
./t-import  0.00s user 0.02s system 54% cpu 0.037 total
./t-inp_str  0.00s user 0.06s system 14% cpu 0.400 total
./t-invert  0.78s user 0.02s system 98% cpu 0.804 total
./t-io_raw  0.05s user 0.26s system 19% cpu 1.571 total
./t-jac  1.80s user 0.06s system 98% cpu 1.884 total
./t-lcm  0.02s user 0.06s system 84% cpu 0.095 total
./t-limbs  0.02s user 0.04s system 74% cpu 0.080 total
./t-lucnum_ui  0.04s user 0.02s system 79% cpu 0.081 total
./t-mfac_uiui  0.01s user 0.04s system 67% cpu 0.065 total
./t-mul  1.09s user 0.05s system 97% cpu 1.163 total
./t-mul_i  0.00s user 0.01s system 46% cpu 0.026 total
./t-nextprime  0.16s user 0.01s system 92% cpu 0.182 total
./t-oddeven  0.00s user 0.01s system 44% cpu 0.027 total
./t-perfpow  0.98s user 0.02s system 98% cpu 1.009 total
./t-perfsqr  0.18s user 0.02s system 95% cpu 0.209 total
./t-popcount  0.01s user 0.02s system 73% cpu 0.038 total
./t-pow  0.50s user 0.00s system 97% cpu 0.523 total
./t-powm  2.34s user 0.01s system 99% cpu 2.367 total
./t-powm_ui  3.69s user 0.08s system 99% cpu 3.774 total
./t-pprime_p  0.27s user 0.02s system 92% cpu 0.310 total
./t-primorial_ui  0.02s user 0.01s system 58% cpu 0.048 total
./t-remove  6.47s user 0.01s system 99% cpu 6.493 total
./t-root  1.14s user 0.02s system 98% cpu 1.172 total
./t-scan  0.00s user 0.06s system 66% cpu 0.102 total
./t-set_d  0.01s user 0.06s system 80% cpu 0.084 total
./t-set_f  0.01s user 0.05s system 76% cpu 0.084 total
./t-set_si  0.00s user 0.06s system 77% cpu 0.083 total
./t-set_str  0.01s user 0.06s system 75% cpu 0.085 total
./t-sizeinbase  0.03s user 0.04s system 78% cpu 0.082 total
./t-sqrtrem  0.85s user 0.06s system 97% cpu 0.927 total
./t-tdiv  2.45s user 0.07s system 99% cpu 2.531 total
./t-tdiv_ui  0.26s user 0.01s system 96% cpu 0.279 total

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

-- 
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]

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]

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

  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?
  
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.

The final repetition count and operand size choices were made to get
good coverage, as measured by automated coverage anaysis.

One may argue that end users don't need to run tests which covers the
libary.  But then remember that compiler bugs affecting GMP are a few
orders of magnitude more common than actual GMP bugs.

-- 
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

[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

Re: mpz reuse test takes too much time

[Torbjörn Granlund]

Vincent Lefevre  writes:

  With GMP 6.1.1 on a Debian GNU/Linux 8 (jessie) machine with
  AMD Opteron(TM) Processor 6272 @ 2.1 GHz, the "reuse" test in
  mpz takes too much time.
  
It is supposed to take a lot of time, as it tests all mpz functions for
correct operand overlap.

  I just did "./configure" and "make" and "make check", and
  noticed that the "reuse" test took around 110 seconds. All
  the other tests are much faster.
  
It makes no sense that it takes 110 seconds.  Your machine must be in
bad health.  Perhaps it has problems with CPU temp and is downclocked?

I tested now on an Intel Atom, which is MUCH slower than a 2.1 GHz Amd
Bulldozer.  I took 44s.  On a high-end machine expect it to take around
10s.

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

mpz reuse test takes too much time

[Vincent Lefevre]

Hi,

With GMP 6.1.1 on a Debian GNU/Linux 8 (jessie) machine with
AMD Opteron(TM) Processor 6272 @ 2.1 GHz, the "reuse" test in
mpz takes too much time.

I just did "./configure" and "make" and "make check", and
noticed that the "reuse" test took around 110 seconds. All
the other tests are much faster.

Individual test:

fraise:...p-6.1.1/tests/mpz> time ./reuse
./reuse  116.58s user 0.60s system 100% cpu 1:57.13 total

System information:

fraise:~/software/gmp-6.1.1> gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

fraise:~/software/gmp-6.1.1> uname -a
Linux fraise 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 
GNU/Linux

fraise:~/software/gmp-6.1.1> ./config.guess
bulldozer-pc-linux-gnu

fraise:~/software/gmp-6.1.1> ./configfsf.guess
x86_64-pc-linux-gnu

-- 
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