Michael VAng <[EMAIL PROTECTED]> writes: > Does there only need to be one FFT line in mlucas.cfg, for the one that > matches your exponent, or do they all have to be there? I've run tests > for the FFT that matches my exponent (352K), but I really do not want to > run tests for all of them... Especially since there are two possible > binary versions for my system... You only need the one for your current FFT length, although if you've got several exponents queued up and they will use different FFT lengths, you'll want to make sure you have an entry for each length. Also, even if you keep the full set of FFT lengths in the .cfg file, it's not necessary to tune each entry prior to running the program - your current FFT length is the only one for which it matters to have the optimal radix set, obviously. > The times between having error correcting on and having it off are not > that far apart in some cases... The shortest non-error corrected time > (33.4s for prefetching off/radix 2) is very close to the shortest error > corrected time (36.0s for prefetching on/radix 6)... In this case would > using error correction be advisable? IMO, a speedup of 7% is nothing tp sneeze at. Also note (as explained in more detail below) the program always does at least the first few hundred thousand iterations with error checking on, and then decides whether to leave it on or turn it off for the rest of the run, depending on whether any roundoff error warnings were generated in this initial phase. Also note: It's not error CORRECTION that's going on, it's error DETECTION, in the sense that if your current exponent is really close to the limit your machine's floating-point precision allows, and you happen to get a dangerously large roundoff error at some point in the computation, the program will be able to detect it and either warn you, or (if the error is dangerously close to the 0.5 mark, at which point it's a coin toss as to whether the number in question should have been rounded up or down) halt the current run. Currently the program can't automatically restart the aborted run and work around the error (there will be such a capability in the next release), but users can do this manually, as follows: 1) temporarily switch to a different FFT radix set than the one that was being used; 2) restore the exponent to the worktodo.ini file; 3) restart the program (which will restart from the last savefile); 4) assuming it gets safely past the problem iteration to the next checkpoint, switch back to the original (and presumbaly more efficient) radix set. Yes, it's not very elegant. but it happens rarely, and as I said, will be automated in the next release a few months from now. But I digress - note that you don't have the simple option of turning off error checking in production (as opposed to interactive timing) runs - instead, on line 4 of mlucas.cfg there is a number N which tells the program ``do at least the first N iterations of every LL test with error checking on.'' If the run of a given exponent gets to this point with no roundoff error warnings, error checking is turned off for the rest of the run. If there were error warnings in the first N iterations, error checking remains on for the rest of the run. On some systems running sans error checking is not significantly slower than running with it, and on these you might want to make N large enough (i.e. larger than the largest exponent you plan to test in the near future, but still small enough to be interpreted as a positive 32-bit signed integer) that error checking is always on. (On my Alphas things run 5-7% faster sans error checking, so I don't do things this way). Hope this helps, and sorry about the long-winded explication. -Ernst _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
