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://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~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
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://www.sesse.net/ _ 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?
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://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://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
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
