Re: Mersenne: LL test efficiency
On Wednesday 27 February 2002 06:26, Steve Harris 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. 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. And I replied: 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. On reflection I can see that there is merit in Steve's idea (provided that restraint is used i.e. not grabbing more work than is neccessary to bridge the rather small exponent gap). I wish to publicly apologise to Steve for any implication that he might be encouraging users to hog exponents. Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error: Another mprime is already running!
On Friday 01 March 2002 00:40, Mary K. Conner wrote: At 05:17 PM 2/28/02 -0500, George Woltman wrote: mprime should only raise this error if the pid in the local.ini file and the current pid are both running mprime (actually comparing the inode values). If there are any Linux experts that can tell me where this test is going wrong, I'd appreciate any insights. This is the first reported failure in 2 years. I'll have a look at the code see what I can come up with. I mucked about with it a bit, and it does appear that if the process running under the pid in the local.ini file is not mprime, it will not raise the error. Comparing inodes, if there is a hard link under two different names, it would raise the error. I.e. someone does 'ln mprime ll', runs ll, then tries to run mprime, the inodes will match although there is no process named 'mprime' running (it is possible to force the process to be named mprime by overwriting argv[0], at least on some systems). Someone might do the hard link if they are trying to save space on installations to run on multiple CPU's, I don't have a multiCPU machine, so I've never done such an installation. That would be a crude and surely unusual way of economising. un*x gurus normal Good Practise to keep executable binaries and scripts seperate from the data, as opposed to the Windows practise of keeping them all mixed up (which makes it much more awkward to set a proper security policy). I think practically every user setup script on unix-like systems (including linux) adds $HOME/bin to $PATH so the obvious place to store mprime is to create a bin directory in your home directory (if it doesn't already exist) put the binary executable in there. On a multi-cpu system you can then set up a directory for each CPU. None of these working directories need to, or should, contain a copy of mprime. So long as each instance has its own copy of local.ini, there will be no problem with Another copy is already running. Of course it is counterproductive to run more instances of mprime than there are processors in the system. (Real processors or virtual processors when running on the new Xeons with hyperthreading? I don't know ... but apparently Windows thinks a dual-processor system has four CPUs ... obviously there is scope for confusion here, especially if you have to rely on what the OS tells you, rather than being able to take off the cover and eyeball the hardware!) Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Two L-L tests at once?
On Thursday 28 February 2002 22:03, Guillermo Ballester Valor wrote: Hi, On Thu 28 Feb 2002 22:19, Brian J Beesley wrote: [ snip ] The difference here is that your method generates memory bus traffic at twice the rate George's method takes advantage of the fact that (with properly aligned operands) fetching the odd element data automatically fetches the adjacent even element data The streams would be alternated : stream0_data(n) , stream1_data(n), stream0_data(n+1), stream1_data(n+1) When fetching data(n) for a stream we also get the other Yes, this scheme does seem to work The memory bottleneck was the first thing I thought, and I was near to discard the idea when I realized that the trig bata would be the same, and the required memory access would be less than double the single stream scheme If a double stream version cost less than double the single one the we can speed up the project a bit On Friday 01 March 2002 00:37, George Woltman wrote: Well, that would be true if SSE2 had a multiply vector by scalar instruction That is, to multiply two values by the same trig value, you must either load two copies the trig value or add instructions to copy the value into both halves of the SSE2 register I can't see that being a major problem Surely there's only one main memory fetch to load the two halves of the SSE2 register with the same value, and surely the loads can be done in parallel since there's no interaction ( M - X; then X - R1 X - R2 in parallel, where X is one of the temporary registers available to the pipeline) On Thursday 28 February 2002 21:20, Steinar H Gunderson wrote: Testing a number in parallel with itself is obviously a bad idea if there occurs an undetected error :-) Sure But the only way there would be a problem here (given that the data values are independent because of the different random offsets) is if there was a major error like miscounting the number of iterations This is relatively easy to test out I'm sort of marginally uneasy, rather than terrified, about running a double-check in parallel with the first test on the same system at the same time Also, I think most people would rather complete one assignment in time T rather than two assignments in time 2T with both results unknown till they both complete Against this is that Guillermo's suggestion does something to counter the relatively low rate at which DCs are completed Regards Brian Beesley _ Unsubscribe list info -- http://wwwndatechcom/mersenne/signuphtm Mersenne Prime FAQ -- http://wwwtasamcom/~lrwiman/FAQ-mers
Re: Mersenne: Two L-L tests at once?
Hi, On Friday 01 Mar 2002 21:22, Brian J Beesley wrote: [ snip ] The memory bottleneck was the first thing I thought, and I was near to discard the idea when I realized that the trig bata would be the same, and the required memory access would be less than double the single stream scheme If a double stream version cost less than double the single one the we can speed up the project a bit On Friday 01 March 2002 00:37, George Woltman wrote: Well, that would be true if SSE2 had a multiply vector by scalar instruction That is, to multiply two values by the same trig value, you must either load two copies the trig value or add instructions to copy the value into both halves of the SSE2 register I can't see that being a major problem Surely there's only one main memory fetch to load the two halves of the SSE2 register with the same value, and surely the loads can be done in parallel since there's no interaction ( M - X; then X - R1 X - R2 in parallel, where X is one of the temporary registers available to the pipeline) We would have to evaluate the cost of memory traffic to load data with two halves the same, or load two differnt data and then double them in two XMM registers I have not any skill in SSE2, no machine to try This morning I've been reading (on the fly) the intel PDF manual, and I saw that the SSE2 was made by Intel engineers thinking more in multimedia than in Mathematics (or GIMPS) There are some elemental ops they could be implemented to do complex number multiplication easy, or a vector by escalar mul, or an exchange within halves :-( Perhaps in SSE3 :) On Thursday 28 February 2002 21:20, Steinar H Gunderson wrote: Testing a number in parallel with itself is obviously a bad idea if there occurs an undetected error :-) Sure But the only way there would be a problem here (given that the data values are independent because of the different random offsets) is if there was a major error like miscounting the number of iterations This is relatively easy to test out I'm sort of marginally uneasy, rather than terrified, about running a double-check in parallel with the first test on the same system at the same time Also, I think most people would rather complete one assignment in time T rather than two assignments in time 2T with both results unknown till they both complete Against this is that Guillermo's suggestion does something to counter the relatively low rate at which DCs are completed I also was worried about that idea, but every time I think, it seems less absurd to me OTOH, I don't know how difficult would be the carry and normalization code of DWT for two _different_ exponents At first approximation, I recall some code I wrote without branches for Glucas, actually a code which makes two streams at once I mean perhaps the cost is small Regards Guillermo _ Unsubscribe list info -- http://wwwndatechcom/mersenne/signuphtm Mersenne Prime FAQ -- http://wwwtasamcom/~lrwiman/FAQ-mers
Mersenne: Re: Two L-L tests at once?
On Fri, Mar 01, 2002 at 08:22:44PM +, Brian J Beesley wrote: Sure But the only way there would be a problem here (given that the data values are independent because of the different random offsets) is if there was a major error like miscounting the number of iterations This is relatively easy to test out Take the worst-case scenario -- some person has cracked the PrimeNet security code and submits fake results Or a cosmic ray hits the CPU just before it calculates the PrimeNet checksum, causing it to send a bad residue Or whatever :-) I don't really see the point of doing it this way -- I'm sure most users would be a lot happier getting twice the speed out of their computers You'd have less problems with early quitters, too /* Steinar */ -- Homepage: http://wwwsessenet/ _ Unsubscribe list info -- http://wwwndatechcom/mersenne/signuphtm Mersenne Prime FAQ -- http://wwwtasamcom/~lrwiman/FAQ-mers
Re: Mersenne: LL test efficiency
On Friday 1 March 2002 15:31, Brian J. Beesley wrote: On reflection I can see that there is merit in Steve's idea (provided that restraint is used i.e. not grabbing more work than is neccessary to bridge the rather small exponent gap). Thanks, Brian. I probably should have mentioned in my original message that it should only take about 10-12 days for the Primenet server to hand out all the assignments in that range (15.16M to 15.30M). Regards, Steve Harris _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error: Another mprime is already running!
At 08:58 PM 3/1/02 +, Brian J Beesley wrote: That would be a crude and surely unusual way of economising Definitely so, but it's the only way I can think of that someone might use a hard link when installing mprime For someone coming from Windows, that might be the way they think to do it I couldn't think of any other non-freak-error way for this error to occur when no process named mprime was running _ Unsubscribe list info -- http://wwwndatechcom/mersenne/signuphtm Mersenne Prime FAQ -- http://wwwtasamcom/~lrwiman/FAQ-mers
