Re: Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
On Sat, Sep 25, 1999 at 10:55:56AM -0500, Herb Savage wrote: >Here a URL with info on it: > > http://bs.cs.tu-berlin.de/~jutta/c/duffs-device.html A side note on the text in that URL: Duff uses `n%8', which a not-so-smart compiler would actually implement as mod 8. A smarter one might do `&7' to mask out the lower 3 bits. /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
John R Pierce wrote: > > There's another trick to this, primarily useful in assembler not C > programming... You can do it in C also. Its called Duff's Device. Its ugly but legal C code. Here a URL with info on it: http://bs.cs.tu-berlin.de/~jutta/c/duffs-device.html Regards, Herb Savage > > Say you unroll something 16 times Take teh actual iteration count > modulo 16, and JMP into the loop at that offset to start with the repeat > counter set to the count/16. i.e. if you need to do, say, 60 iterations of > the inner code, thats 48 + 12, so you set the loop count to 3, and jump to > the 4th block of the 16 (16-12 = 4) > > Anyways, prime95 is HEAVILY unrolled, using assembler macros to generate the > inline linear inner 'loops'. > > -jrp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
> Sounds like loop unrolling is what you're talking about. Most modern compilers (try > to) do this already automatically. However, I've experimented on different variations > of this with the Linux source to, I think, v16 or so, where it seemed possible to > attain small benefits from various variations of look-unrolling. The biggest problem > here is that the number of iterations isn't divisible by any fixed amount. Because of > that the last few iterations need to be done "manually" outside the unrolled block. > The main advantage of such unrolling comes from not needing to check for the number > of timed events present in Prime95/mprime between each iteration - due to cache > considerations actually copying the whole FFT code out as many times as needed > instead of just using calls to it is probably even worse. There's another trick to this, primarily useful in assembler not C programming... Say you unroll something 16 times Take teh actual iteration count modulo 16, and JMP into the loop at that offset to start with the repeat counter set to the count/16. i.e. if you need to do, say, 60 iterations of the inner code, thats 48 + 12, so you set the loop count to 3, and jump to the 4th block of the 16 (16-12 = 4) Anyways, prime95 is HEAVILY unrolled, using assembler macros to generate the inline linear inner 'loops'. -jrp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
Philippe Trottier wrote: > I don't know how the software of primenet work but When I wanted a really > fast execution I was doing like so (The last time I coded it was in 1991) *snap* Sounds like loop unrolling is what you're talking about. Most modern compilers (try to) do this already automatically. However, I've experimented on different variations of this with the Linux source to, I think, v16 or so, where it seemed possible to attain small benefits from various variations of look-unrolling. The biggest problem here is that the number of iterations isn't divisible by any fixed amount. Because of that the last few iterations need to be done "manually" outside the unrolled block. The main advantage of such unrolling comes from not needing to check for the number of timed events present in Prime95/mprime between each iteration - due to cache considerations actually copying the whole FFT code out as many times as needed instead of just using calls to it is probably even worse. I've posted about this suggestion before on this list, so I hope the possible optimizations have been taken into consideration in v19 already, altough with the exponent increasing the FFT code is starting to take more and more time and the optimization of all the rest of the code become less important. I seem to also have forgotten the rest of the optimizations I've toyed with ;> -Donwulff _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
HI! Anyone tought of send ing these P and Q once a month to the server.. in the case where someone would abandon a quest, it could be continued by someone else ... >Notice that in v19 if you set it to get 10 Million range numbers you get a warning >about it taking a year on a 500 Mhz P-2, and odds of 1 in 250,000. If the price would be won the split would be according to CPU cyle or CPU time !?!?!?! Philippe BTW for the nice Screen Saver interface I would suggest some fun GFX (something easy to draw) from the residue of each Iteration with a Bar decreasing with the work to do on the exponent I don't know how the software of primenet work but When I wanted a really fast execution I was doing like so (The last time I coded it was in 1991) A=0 "do it" do job on A do job on A do job on A do job on A ... (as many times it's logical depend on size order) do job on A if Avalue do it backward till it's OK ( if you pass straight ahead oops) JUMP "done" Other of my trick was to do the same unchecked bunch of ADD then till a register create a CPU fault, trap the fault and see were is the registers =) That was removeing all the checking of condition till I had a fault ... saving many little cycles These are just theory Philippe _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
"Brian J. Beesley" wrote: > On 20 Sep 99, at 1:06, Rick Pali wrote: > > > The only question that comes to mind is if you had to plough through > > factoring before you got to the LL test...but then I realise that you still > > wouldn't be done if that were true. > > You don't have to pre-factor, if you choose "Test" or "Time" from the > "Advanced" menu. > > > > I signed up for an exponent in the 33mil range and the factoring alone took > > 13 days on a P3-500. > > Ah, so we're maybe not doing enough trial factoring. I guess your > completion time is about a year; trial factoring should take between > 5% and 10% of the time for a LL test, & 13 days is only about 3.5%. I > think we should probably go one bit deeper, this would double the > trial factoring time - but would save the whole year, if you managed > to find a factor. > > > I'd originally does it for testing purposes, but after > > that I've just got to let it continue. :-) > > Well, why not? > > > > In a year's time, I'd love to see some numbers on how many signed up for tem > > million digit numbers and later quit for smaller exponents... > > I think you need to be a true enthusiast to take on a single test > taking ~ 1 year. Lots (attracted by ca$h) won't realise what it > means, for a week or two, & may then drop out 8-( To avoid this > happening to too many people, I think we should be a bit more upfront > that testing a 10 million digit number is going to take about a year, > even on a state-of-the-art system. > > I have several fastish systems - a couple of them are running QA > stuff at the moment - I may voluntarily take on a 10 million digit > number on _one_ of them, but I certainly wouldn't choose to run tests > of that length on _all_ of them! > > Regards > Brian Beesley > _ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers Notice that in v19 if you set it to get 10 Million range numbers you get a warning about it taking a year on a 500 Mhz P-2, and odds of 1 in 250,000. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Decamega Tests (was: RE: Mersenne: GIMPS client output)
On 20 Sep 99, at 1:06, Rick Pali wrote: > The only question that comes to mind is if you had to plough through > factoring before you got to the LL test...but then I realise that you still > wouldn't be done if that were true. You don't have to pre-factor, if you choose "Test" or "Time" from the "Advanced" menu. > > I signed up for an exponent in the 33mil range and the factoring alone took > 13 days on a P3-500. Ah, so we're maybe not doing enough trial factoring. I guess your completion time is about a year; trial factoring should take between 5% and 10% of the time for a LL test, & 13 days is only about 3.5%. I think we should probably go one bit deeper, this would double the trial factoring time - but would save the whole year, if you managed to find a factor. > I'd originally does it for testing purposes, but after > that I've just got to let it continue. :-) Well, why not? > > In a year's time, I'd love to see some numbers on how many signed up for tem > million digit numbers and later quit for smaller exponents... I think you need to be a true enthusiast to take on a single test taking ~ 1 year. Lots (attracted by ca$h) won't realise what it means, for a week or two, & may then drop out 8-( To avoid this happening to too many people, I think we should be a bit more upfront that testing a 10 million digit number is going to take about a year, even on a state-of-the-art system. I have several fastish systems - a couple of them are running QA stuff at the moment - I may voluntarily take on a 10 million digit number on _one_ of them, but I certainly wouldn't choose to run tests of that length on _all_ of them! Regards Brian Beesley _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: GIMPS client output
Rick, Glad to see *somebody's* awake!! >From: Eric Hahn > >> P.S. At the 79.3M range, you'll probably not want to set it >> at 100 iterations... Per iteration time on 266MHz PII with >> 64MB RAM is 58.781 seconds!!! > >The only question that comes to mind is if you had to plough >through factoring before you got to the LL test...but then I >realise that you still wouldn't be done if that were true. You're right! Even on a P3-500, it'd take 7-8 months to plough through all the factors to 2^72. I intentionally told it that it had been factored thru 2^73 to prevent it from doing such. This was for a test I was running... >I signed up for an exponent in the 33mil range and the factoring >alone took 13 days on a P3-500. I'd originally does it for testing >purposes, but after that I've just got to let it continue. :-) I've got 2 machines working on 10M digit exponents. One will work until completion, while the other will be forced to trial-factor only (a feature not offered in v19 which I've mentioned to George). >In a year's time, I'd love to see some numbers on how many signed >up for tem million digit numbers and later quit for smaller >exponents... Well, let's see... You got yours assigned Sept. 5 at 3:38 UTC. 14 exponents assigned, 3 factored, 11 still in progress... and counting... Interesting to note, however, that 2 of the exponents factored and 1 still in progess had factors listed on Alex Kruppa's site: http://www.informatik.tu-muenchen.de/~kruppa/M33M/index.html before 10M digit exponents were assigned by IPS. Which ones?? 33,219,341 and 33,219,469 and 33,219,707 (33,219,341 was assigned by IPS to Alex, BTW ) Eric Hahn _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: GIMPS client output
From: Eric Hahn > P.S. At the 79.3M range, you'll probably not want to set it > at 100 iterations... Per iteration time on 266MHz PII with > 64MB RAM is 58.781 seconds!!! The only question that comes to mind is if you had to plough through factoring before you got to the LL test...but then I realise that you still wouldn't be done if that were true. I signed up for an exponent in the 33mil range and the factoring alone took 13 days on a P3-500. I'd originally does it for testing purposes, but after that I've just got to let it continue. :-) In a year's time, I'd love to see some numbers on how many signed up for tem million digit numbers and later quit for smaller exponents... Rick. -+--- [EMAIL PROTECTED] http://www.alienshore.com/ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS client output
>Iteration: 164000 / 8410531 [1%]. Clocks: 115665753 = 0.496 sec. > >Might be nice to display the percentage out to an accuracy that changes >every hundred iterations. Hmm, looks like that's an integer of the >percentage, not rounded. Guess it doesn't matter. For the one I'm >working on it looks like 3 decimal places would be needed to see a >change every 100 iterations. v19 allows this by manually adding 'PercentPrecision=' to the PRIME.INI file (Prime95 must be stopped and exited before editing, and then restarted). The valid range after the '=' is 0 to 6, therefore you can have it say: Iteration: 164000/8410531 [1.949936%]. Per iteration time: 0.496... Iteration: 164100/8410531 [1.951125%]. Per iteration time: 0.496... Mind you, even at the limit of v19 (79.3M), setting it to a value of 4, and having screen outputs at every 100 iterations, will still cause the value to increase (although by 0.0001%) Eric Hahn P.S. At the 79.3M range, you'll probably not want to set it at 100 iterations... Per iteration time on 266MHz PII with 64MB RAM is 58.781 seconds!!! (Yes, it's true, but I'm also just checking to see if anybody's awake :)) _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: GIMPS client output
> Might be nice to display the percentage out to an accuracy that changes > every hundred iterations. Hmm, looks like that's an integer of the > percentage, not rounded. Guess it doesn't matter. For the one I'm > working on it looks like 3 decimal places would be needed to see a change > every 100 iterations. This is changed in V19 (currently in Beta). I believe (George correct me if I'm wrong) that you can specify it up to 6 decimal places. -Lucas _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: GIMPS client output
From: Darxus > Iteration: 164000 / 8410531 [1%]. Clocks: 115665753 = 0.496 sec. > > Might be nice to display the percentage out to an accuracy that > changes every hundred iterations. If you're using version 19, add "PercentPrecision=3" to the prime.ini file. If you want more than three decimal places, change the number...I believe it'll go up to six. I believe that four should be sufficient as even M33219281 changes every three or four hundred iterations with three places displayed. Rick. -+--- [EMAIL PROTECTED] http://www.alienshore.com/ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
