Will Any Current 100M Digit LL Tests Finish?

[jinydu]

I haven't heard anything since my latest post to the M100,000,039 thread.

[petrw1]

There are 10 assignments above 400M and even a few above 900M.

Two questions:

1. I thought Prime95 could not handle exponents above about 560M?
2. Will these last few EVER EVER EVER EVER EVER finish? And how long would even an i7 with all 8 cores working together take ... EONS?

[James Heinrich]

Originally Posted by petrw1

Will these last few EVER EVER EVER EVER EVER finish? And how long would even an i7 with all 8 cores working together take ... EONS?

LL testing M900,000,000 on an i7 @ 3.2GHz would take ~21 years on a single core. I'm not sure how well the i7 scales with multiple threads, especially the virtual hyperthreaded ones, but assuming a nominal 20% inefficiency slowdown per additional worker thread, 8-threaded i7 throughput should be around 4x-5x that of a single thread, so somewhere around 4-5 years to complete is about as fast as you could possibly get it done on current hardware. A dual-core E8400 @ 3.0GHz would take about 13 years.

Originally Posted by petrw1

I thought Prime95 could not handle exponents above about 560M?

the 32M FFT seems to be defined for M521,500,000 to M596,000,000 so that might be the limit. TF breakeven points (according to the last list I saw) are only defined up to M516,000,000 => 2^80 (presumably 2^81 would start around M620,000,000 and so forth). I'm not sure when Prime95 will include FFTs larger than 32M.

[petrw1]

Just for fun I tried to use Manual Assignments to get one over 999M and I did...I was suprpised. It gave me a "Next Update" date of: 2009-10-15 22:45. I don't know what would happen if I tried to run the LL test or what FFT I would get. I don't intend to keep it. I might not live to see it finish.

[10metreh]

Originally Posted by petrw1

Just for fun I tried to use Manual Assignments to get one over 999M and I did...I was suprpised. It gave me a "Next Update" date of: 2009-10-15 22:45. I don't know what would happen if I tried to run the LL test or what FFT I would get. I don't intend to keep it. I might not live to see it finish.

[off-topic]I miss your old avatar.[/off-topic]

[ewmayer]

Originally Posted by James Heinrich

the 32M FFT seems to be defined for M521,500,000 to M596,000,000 so that might be the limit.

That upper limit seems dangerously high - for Mlucas in SSE2 mode I calculate 592-593M as the cutoff for the 32M FFT. For a 1000-iteration timing test that gives a maximum-fractional-output error of around 0.30 (this is on a single CPU of a 2GHz quad-core Athlon, running in 32-bit mode):

CPU Family = Pentium, OS = Linux, 32-bit Version, compiled with Gnu C, Version 4.2.1.
INFO: CPU supports SSE3 instruction set, but only USE_SSE2 used in current Mlucas version.

Mlucas selftest running.....

M592400713: using FFT length 32768K = 33554432 8-byte floats.
this gives an average 17.654917031526566 bits per digit
Using complex FFT radices 32 32 32 32 16
1000 iterations of M592400713 with FFT length 33554432 = 32768 K
Res64: 994DD6B24F452451. AvgMaxErr = 0.228316789. MaxErr = 0.281250000. Program: E3.0x
Clocks = 01:21:03.399

Using an exponent ~596M gives a max-fractional-error of 0.375, which is - especially based on the small number of iterations used in the test - getting uncomfortably close to the dangerous range - note that the code only checks the roundoff error every 32nd iteration, so likely slightly underestimates the true maximum:

M596000021: using FFT length 32768K = 33554432 8-byte floats.
this gives an average 17.762184768915176 bits per digit
Using complex FFT radices 32 32 32 32 16
1000 iterations of M596000021 with FFT length 33554432 = 32768 K
Res64: 807BDF6E0E27186B. AvgMaxErr = 0.266491573. MaxErr = 0.375000000. Program: E3.0x

George, what kind of ROE numbers do you see for this Prime95 in SSE2 mode for this exponent and FFT length?

[petrw1]

Originally Posted by 10metreh

[off-topic]I miss your old avatar.[/off-topic]

Thanks...

Actually this is only the second one I've had in 2.5 years. The previous one (my first) was assigned to me by the Gerbils. I thought it was cool since I play guitar. But then I thought that some day I need to pick my own. This new one has some history and is "cool" - pun intended but I don't L-O-V-E it. When I have a few hours (literally) to go through my thousands (literally) of JPGs I'll find another.

[Prime95]

One data point from prime95 (roundoff error over 590 iterations):

Iteration: 590 / 595999993 [0.00%]. Round off: 0.2148437500 to 0.2851562500. Per iteration time: 2374.956 ms.

[ewmayer]

Hi, George:

Just out of curiosity, what kind of hardware was that run on - a Core2?

I wanted to get a more-rigorous roundoff error profile for this exponent/FFT-length, so I turned on every-iteration ROE checking in my SSE2 carry-propagation macros and am going to run a million iterations on a single CPU of my 1.66GHz Core2Duo laptop at home - here the results from the first 20-thousand-some iterations, you see two RO > 0.4 warnings, one at the if-you-see-more-than-a-few-of-these-your-run-is-probably-hosed 0.4375 level:

M596000021 Roundoff warning on iteration 1363, maxerr = 0.406250000000
[May 02 05:49:52] M596000021 Iter# = 10000 clocks = 08:18:48.359 [ 2.9928 sec/iter] Res64: 7BAC6AB5585D58BB. AvgMaxErr = 0.303582422. MaxErr = 0.406250000
[May 02 14:09:19] M596000021 Iter# = 20000 clocks = 08:19:06.920 [ 2.9947 sec/iter] Res64: D5E84DD90712984D. AvgMaxErr = 0.304522803. MaxErr = 0.375000000
M596000021 Roundoff warning on iteration 21114, maxerr = 0.437500000000

Again, it may simply be that my code has a greater average level of ROE than George's, but I'm not cutting many corners in e.g. computing the sincos multipliers and DWT weights, so I wouldn't have thought the disparity would be terribly great.

George, might I trouble you to similarly run a few 10K iterations on this exponent @32M FFT using Prime95/SSE2 with every-iteration ROE checking turned on? If there is in fact a significant disparity in roundoff accumulation levels between the two codes, I`d like to know.

[Prime95]

This is a Core 2 Duo.

Iteration: 10290 / 596000021 [0.00%]. Round off: 0.2187500000 to 0.3125000000. Per iteration time: 1812.825 ms.

[ewmayer]

Thanks for the cycles, George - I halted my Mlucas run at 50000 iterations, because that told me all I needed to know there, i.e. that the formula I use to auto-compute FFT breakpoints is properly tuned for my code's ROE levels, and kicked off a run of 595999993 using Prime95, which I'll let go to a million iterations to see if there are any ROE outliers close to 0.4.

Note that your ROE range of [0.21875, 0.3125] is fairly consistent with my AvgMaxErr ~0.30 data (which measures the average over each iteration block of the maximum per-element ROE seen on each iteration), but my outliers are larger - not to any worrisome degree, mind you, this translates to a maximum exponent at any given FFT length of around 0.5% less than for your code. But it does indicate that it might be worthwhile to re-examine the code portions that trade off more accuracy for speed than is true for the bulk of the code.