On Wednesday 27 February 2002 06:26, you wrote: > For those of you interested in optimizing efficiency of LL testing: > > We are approaching first time tests of 15.30M exponents, at which point the > Prime95 program will start using an 896K FFT. However, the P4-SSE2 section > of the program will start using that larger FFT size at 15.16M exponents, > making it (relatively) inefficient to test exponents between 15.16M and > 15.30M on a P4.
This is undoubtedly true. However a P4 should still run tests in this range faster than anything else (even adjusted for clock speed). > > Since the Primenet server doesn't take this into consideration when > assigning exponents, I would suggest you all have enough exponents queued > up on your P4s before the server reaches 15.16M to keep them busy until it > reaches 15.30M. I know there are other ways around it, but that is the > simplest. Whilst I appreciate Steve's motives in making this suggestion, I have a philosophical problem with it. If a few people hog these exponents, other people with an equal need to "economise" will be unable to get them. Overall I don't see that there is much gain, whilst there is scope for resentment against the "hoggers" in a similar (but possibly less extreme) way to the resentment felt against "poachers" of first-time LL test assignments. I would suggest instead: (a) if you have both a P4 and a "something else" running LL tests and you get an exponent in an "inefficient" range on the P4 system, swap assignments between the P4 and the "something else". (b) pick up exponents at a time designed to avoid exponents in a range you don't want to test. My guess is that if you pick up assignments between 07:00 and 10:00 GMT then, for the next month or so at least, you're very unlikely to get exponents > 15,160,000. By then you will probably be able to switch to picking up around 05:30 GMT and be very unlikely to get an exponent less than 15,300,000. Unless lots of people start following Steve's advice... I've suggested before that the client/server communication should include a "preferred exponent range" so that, when the server is allocating a new assignment, it tries to pick one within the range requested by the client rather than just assigning the lowest available exponent. I think this would remove the problem identified by Steve, and also any possible friction caused by adoption of Steve's suggestion. I'm well aware that there are practical problems in implementing my suggestion. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
