Re: mpz reuse test takes too much time

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

Re: mpz reuse test takes too much time

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

Re: mpz reuse test takes too much time

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

Re: mpz reuse test takes too much time

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

Re: mpz reuse test takes too much time

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