"Marco Bodrato" <bodr...@mail.dm.unipi.it> writes: I tried the test on a 18-years old 32-bits CPU I'm currently using. A single 8000-bit Miller-Rabin round took 20 seconds with mini-gmp. That's why I reduced the size. With 2000-bit operands I assume the worst execution time will be reduced by a factor 18. The hypothesis "its time varies hugely" is surely true. Before the changeset 17099, on my machine, fluctuations between 2 and 60 seconds where the norm. Of course a seed that require many MR rounds on big operands is unlikely... I see. I am less worried now. Let's mark the bug as done!
If hugely varying operand sizes are motivated (which is the case for "big"-GMP with its many operand size dependent algorithm choices) one could make operand size selection more complex to allow good coverage and less time fluctuations. One trick is to make random sizes within a series of, fixed intervals. I did that for mpz/t-mul.c some years ago. I have some vague plans of writing a new test framework where that would be a fundamental mechanims. One other feature is allowing truly huge operands, something we currently don't test. -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
