100M madness

[stars10250]

Is it really all that crazy to contemplate this? I've been reading posts that say it would take too long with current technology to try for a 100M digit monster. Help me out here:

My current E8500 can LL a 12M digit number in about 28 days (actually it can do 2LL's in that time, but just consider 1 for now). If we assume the calculation is linear (is it?), then we're looking at about 233 days (~8 months) for a 100M digit number. That's a long time, but...

Suppose we take things up a notch and run on a new Nehalem processor in a few months, where we're hoping to get true quad performance. One could run the 100M number on a single core, and run 3 other more reasonable LL's on the other cores, and still outperform todays best Penryn quad that people report getting about 3 cores-worth of performance. Nehalem may even shorten the 8 month estimate. Some benchmarks put it at 30% better performance than Penryn, but I have no idea what we'll actually see on prime95. If the 30% performance gain applies to prime95, 8 months would shrink below 6 months and one could do 2 100M numbers in a year on a single core!

All this boils down to linearity, so is it?

[Prime95]

Originally Posted by stars10250

Is it linear?

No. The iteration speed is almost linear, but you need to run more iterations.

Also, Nehalem worries me. The 256KB L2 cache is *real* small.

[jinydu]

It's definitely much harder than linear. Assuming that iteration time is proportional to FFT length, the smallest 100M digit exponent would take over 61.6 times longer than 2^43112609 - 1.

Take a look at this (http://www.mersenneforum.org/showthr...ies#post141900). Also see (http://www.mersenneforum.org/showthread.php?t=10660), post #6.

[stars10250]

Ok, I'm an idiot. All I had to do was use the benchmark page to estimate the time for my processor to test a 100M digit number. For my E8500, the estimate is 4 years, 150 days...a little long for my patience level and certainly not a linear extrapolation from my 12M digit numbers.

Regarding Nehalem, will the large L3 cache help offset the small L2? Presumably the Quickpath interconnect will get closer to all-core performance. I was really hoping to get one and move up the producers list and crush you guys. Don't burst my bubble!

[retina]

Originally Posted by stars10250

Presumably the Quickpath interconnect will get closer to all-core performance.

I was wondering this also. Is Windows smart enough to run on NUMA systems and make intelligent decisions about memory allocation and thread deployment?

[Andi47]

Originally Posted by Prime95

Also, Nehalem worries me. The 256KB L2 cache is *real* small.

Can P95 version 25.6 use L3-cache? The Nehalem-processors will have 4 - 12 (24 for servers) MB shared L3, depending on the processor-type.

[ldesnogu]

Originally Posted by Andi47

Can P95 version 25.6 use L3-cache? The Nehalem-processors will have 4 - 12 (24 for servers) MB shared L3, depending on the processor-type.

The L3 cache latency (number of cycles to get data from it to the CPU) is much higher than the L2 cache latency, so this might be an issue if you don't have prefetch instructions that help hide data movement between the various cache levels.

BTW that makes me wonder: are there processors that have different data prefetch instructions that target different memory hierarchy levels?

[davieddy]

Originally Posted by Prime95

No. The iteration speed is almost linear, but you need to run more iterations.

Or more accurately "the time per iteration is almost linear".
Furthermore the probability of finding a prime is inversely
proportional to the exponent.

"Madness" is apt ATM

[philmoore]

Originally Posted by Prime95

The iteration speed is almost linear, but you need to run more iterations.

And since the number of iterations is equal to the exponent (minus 2), the total time to do a Lucas-Lehmer test is approximately proportional to the square of the exponent. Double the exponent, quadruple the run-time.