any body play with the soft fft crossover yes?
any body have a chance to play with these yet
any good suggestions on settings any success sotries or horror stories? 
Re: any body play with the soft fft crossover yes?
[quote="crash893"]any body have a chance to play with these yet
[/quote]Well sorry not yet! I have one in que tho, it's at 15,343,000 running on my PIII. I plan to just use default's. LL will start about Oct.31. Right after that I could tell whether it picked the lower FFT. Later on, about christmas time, I could tell you how roundings worked out. So with a bunch of patience you'll have at least one result RSN. :) 
Re: any body play with the soft fft crossover yes?
[quote="crash893"]any body have a chance to play with these yet
any good suggestions on settings any success sotries or horror stories?[/quote] Like svempasnake, I haven't played with the settings, but I can tell how things worked out with the default settings. In v22.8+ ( information comes from results.txt ): M7762439: ran at FFT of 384K w/ roundoff checking 1 roundoff error of 0.408 result unverified because I just completed it today M7761913: ran at FFT of 384K w/ roundoff checking 1 roundoff error of 0.430 result verified to be correct In v22.5 ( don't have access to results.txt for these; # of roundoff errors is from LUCAS_V.TXT and largest roundoff error is from my own memory ): M6530971: ran at FFT of 320K w/ roundoff checking 4 roundoff errors < 0.43 result verified to be correct M6528541: ran at FFT of 320K w/ roundoff checking 3 roundoff errors < 0.43 result verified to be correct 
Just started processing 8904871 this evening using v22.8. From the results file...
[code:1]Trying 1000 iterations for exponent 8904871 using 448K FFT. If average roundoff error is above 0.2414, then a larger FFT will be used. Final average roundoff error is 0.23979, using 448K FFT for exponent 8904871. [/code:1] I'm not sure what typical values are for the average roundoff, but it looks to me like I just squeaked in under the limit 8) . This one should finish Monday afternoon; I'll post results then. Next in the queue is 8980007, which is just over the P4 448/512K breakpoint at 8.97M. I'll post numbers for that one too. 
[quote="dswanson"]Just started processing 8904871 this evening using v22.8. From the results file...
[code:1]Trying 1000 iterations for exponent 8904871 using 448K FFT. If average roundoff error is above 0.2414, then a larger FFT will be used. Final average roundoff error is 0.23979, using 448K FFT for exponent 8904871. [/code:1] I'm not sure what typical values are for the average roundoff, but it looks to me like I just squeaked in under the limit 8) . This one should finish Monday afternoon; I'll post results then. Next in the queue is 8980007, which is just over the P4 448/512K breakpoint at 8.97M. I'll post numbers for that one too.[/quote] The P4 448/512K breakpoint is 8908000 for v22.8+, so 8.98M is not in the softcrossover range. George posted the new breakpoints to the Mersenne mailing list on August 14th. He has not updated any of the webpages to reflect these new breakpoints yet. Oh, btw, for the exponents I posted above, none of them actually activated the softcrossover feature, but I thought the roundoff errors I got would be helpful anyways. 
Ahh, OK. In that case, George needs to update the ranges shown on his benchmark page. And the result from 8904871 should be interesting, since it's so close to the cutoff.

Nick, you're right, the new ranges were in the mailing list. Here's George's message from that list, for those who don't subscribe...
[code:1]This table shows FFT size, v21 x87 crossover, v22.8 x87 crossover, v21 SSE2 crossover, v22.8 SSE2 crossover. As you can see v22 is more liberal with x87 crossovers and more conservative with SSE2 crossovers. 262144 5255000 5255000 5185000 5158000 327680 6520000 6545000 6465000 6421000 393216 7760000 7779000 7690000 7651000 458752 9040000 9071000 8970000 8908000 524288 10330000 10380000 10240000 10180000 655360 12830000 12890000 12720000 12650000 786432 15300000 15340000 15160000 15070000 917504 17850000 17890000 17660000 17550000 1048576 20400000 20460000 20180000 20050000 1310720 25350000 25390000 25090000 24930000 1572864 30150000 30190000 29920000 29690000 1835008 35100000 35200000 34860000 34560000 2097152 40250000 40300000 39780000 39500000 2621440 50000000 50020000 49350000 49100000 3145728 59400000 59510000 58920000 58520000 3670016 69100000 69360000 68650000 68130000 4194304 79300000 79300000 78360000 77910000 Now the gotcha. In v22.8, FFT crossovers are flexible. If you test an exponent within 0.2% of a crossover point, then 1000 sample iterations are performed using the smaller FFT size and the average roundoff error calculated. If the average is less than 0.241 for a 256K FFT or 0.243 for a 4M FFT, then the smaller FFT size is used. Brian Beesley has been a great help in investigating revised crossover points and analyzing the distribution of round off errors. We noticed that consecutive exponents can have a pretty big difference in average roundoff error (e.g. one exponent could be 0.236 and the next 0.247). This is why I elected to try the flexible approach described above. The 0.241 to 0.243 average was chosen hoping for about 1 iteration in a million generating a roundoff error above 0.4. We might change the 0.241 to 0.243 constants with more data  it is hard to get enough data points to accurately measure 1 in a million occurrences. One downside is the server does not know which FFT size is used and will credit you based on the v21 x87 crossovers. Thus, if you are a lucky person, you might get "bonus" CPU credit where you test the exponent at a smaller FFT size and the server credits you based on the larger FFT's timing.[/code:1] 
As promised, here are the results for 8904871.
First, the processor and version number data... [code:1]Intel(R) Pentium(R) 4 CPU 1.80GHz CPU speed: 1807.56 MHz CPU features: RDTSC, CMOV, PREFETCH, MMX, SSE, SSE2 L1 cache size: 8 KB L2 cache size: 512 KB L1 cache line size: 64 bytes L2 cache line size: 64 bytes TLBS: 64 Prime95 version 22.8, RdtscTiming=1 [/code:1] And the results, cutandpaste from the results file (edited heavily for brevity). Things started relatively quietly, with only 2 errors in the first 5.4M... [code:1][Fri Sep 13 18:33:37 2002] Trying 1000 iterations for exponent 8904871 using 448K FFT. If average roundoff error is above 0.2414, then a larger FFT will be used. Final average roundoff error is 0.23979, using 448K FFT for exponent 8904871. [Sat Sep 14 04:30:30 2002] Iteration: 1276787/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. For added safety, redoing iteration using a slower, more reliable method. Continuing from last save file. [Sun Sep 15 00:26:09 2002] Iteration: 3822131/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Continuing from last save file. Disregard last error. Result is reproducible and thus not a hardware problem. For added safety, redoing iteration using a slower, more reliable method. Continuing from last save file.[/code:1] But then it got really exciting for the next 1.2M... [code:1]Iteration: 5455889/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Iteration: 5575813/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Iteration: 5629431/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Iteration: 5994211/8904871, ERROR: ROUND OFF (0.4375) > 0.40 Iteration: 6175814/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Iteration: 6380548/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Iteration: 6558839/8904871, ERROR: ROUND OFF (0.40625) > 0.40[/code:1] Then quieted back down for the final 2.3M... [code:1]Iteration: 7548466/8904871, ERROR: ROUND OFF (0.40625) > 0.40 Iteration: 8640014/8904871, ERROR: ROUND OFF (0.40625) > 0.40 [Mon Sep 16 16:39:44 2002] UID: dswanson/pc1800B, M8904871 is not prime. Res64: 7563B6330A3BDDC0. WY1: F5DFC11B,519163,0B000B00 [/code:1] Total: 11 roundoff errors in 8.9M, pretty close to George and Brian's goal of 1 per million. But, as should be expected for a randomish process, the errors were certainly NOT uniformly distributed! George, how can I find out if my residual matches that from the first run of this number? Of course, given that this number was available only because its first run also had errors reported, a negative answer is probable and only means I'll have to wait for the triplecheck (or possibly quadruplecheck, if both mine and the previous run are bad) to know for sure. 
It matched.

:D :D 8)

All times are UTC. The time now is 18:55. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2020, Jelsoft Enterprises Ltd.