Hi all,
At 04:56 PM 4/3/99 -0600, Ken Kriesel wrote:
>Since we now have a wealth of exponents to be tested or retested,
>requiring a total expenditure of billions of cpu-hours, perhaps
>we could introduce a little more formalism into the program-validation
>process. I volunteered months ago to test 1 or 2 exponents in each
runlength.
>Several have completed. Brian Beesley offered to double-check my
>results, and George has assigned them to Brian as double-checks.
>The nature of the just-discovered bug suggests that more test cases are
>in order.
>
>I propose the following be considered, for each future version released
>(and for the versions in heavy use currently):
>1. Code review by qualified volunteers.
A good idea for the C code, I doubt the assembly code qualifies.
>2. George and such other people as are qualified, determine which exponents
>make good test cases, based on a review of the code.
My input:
1) Those near the end of each range should be checked for
excessive convolution error. In fact, it would be nice it the QA
suite recommended the crossover points for the FFTs.
2) Exponents that are close to a multiple of the FFT length.
Crandall's "magic numbers" are very sensitive here.
>3. Volunteers with some cpu-power run LLtests and double-checks on the test
>cases selected.
As pointed out earlier, a few hundred iterations *should* suffice.
But Ken may decide a few more lengthy checks are required.
And as v17 pointed out, the shifting code needs to be checked
in the above tests.
>Since this project is in a sense George's baby, I feel he has the right
>to ok or nix this. If he says ok, I volunteer to be the contact point
>for volunteers to enlist as either code reviewers, testers, or both.
>After a week or two I will summarize to George.
OK, I never turn down a volunteer! I hereby appint Ken the coordinator
of the official GIMPS QA project.
First order of business is a plan of action - formulating the QA test suite.
How much CPU power are we going to require? Would enough tests to keep
5 volunteers busy for 24 hours suffice? Will the ports run shorter suites?
This QA suite will not be my baby, so don't be shy folks in chiming
in with ideas or offering to help Ken out. I'll put in whatever hooks
you folks need.
Now for some good news-------->
Prime95 v19 is under way. It involves rewriting ALL the FFT code!
So this QA project is quite timely.
What's new in v19? It should support FFT lengths from 32 up to 4M
with PFA lengths (3*power-of-two and 5*power-of-two) supported.
It has a slightly modified memory model that should be more efficient in
using the Pentium's TLB (translation look-aside buffers) cache for
larger FFT sizes. A little less memory traffic for some FFT lengths.
P-1 factoring support.
What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n)
GCD to make P-1 and ECM factoring on larger exponents feasible. A more
memory efficient but slower stage 2 for large exponents. Several FFT sizes
are not coded yet. Obviously, don't expect v19 anytime soon!
Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster.
Oh, and by the way, the re-engineered assembly code will be easily usable
in other large integer programs.
Best regards,
George
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
