If a deaf man :poop:s a forest does he make a sound?

In a futile attempt to get this thread back on track...

The [URL="http://www.hogranch.com/mayer/README.html"]Mlucas[/URL] 3.x (prerelease) verification run has completed.

The verification was run on a [URL="http://www.sun.com/servers/highend/m9000/index.xml"]Sun SPARC Enterprise M9000 Server[/URL] using 16 x 2.52Ghz SPARC64 VII cores with the Solaris 10 operating system.

All residues were in line with Tony's results.

The final output was...

[CODE]M42643801 is a new MERSENNE PRIME!!![/CODE]

We now have the following runs complete.

1) The original Prime95 on Intel Core 2 find from Odd Magnar Strindmo
2) Ernst running the final iterations from the last save file from Odd's original Prime95 run
3) The Glucas verification started on Itanium 2 and completed on Nehalem
4) The Glucas verification completed on the Itanium 2
5) Mlucas verification on SPARC64 VII

Jeff is also currently running another Glucas / Itanium 2 verification.

Cheers, Rob.

No, the attempt wasn´t futile...
Congrats!
We´re now more than sure we have a new one.

[QUOTE=rgiltrap;177695]In a futile attempt to get this thread back on track...

The [URL="http://www.hogranch.com/mayer/README.html"]Mlucas[/URL] 3.x (prerelease) verification run has completed.

The verification was run on a [URL="http://www.sun.com/servers/highend/m9000/index.xml"]Sun SPARC Enterprise M9000 Server[/URL] using 16 x 2.52Ghz SPARC64 VII cores with the Solaris 10 operating system.

All residues were in line with Tony's results.

The final output was...

[CODE]M42643801 is a new MERSENNE PRIME!!![/CODE][/QUOTE]

Many thanks for finding machine (and personal time) to do this, Rob - I look forward to working with you to resolve the parallelization issues for non-power-of-2 runlengths, so next time around we can use the optimal FFT length and really blast through the verification.

[quote=lycorn;177696]
We´re now more than sure we have a new one.[/quote]
Yep. I'd guess about 110% certain.

Let's get the next prime number.

Think Prime95 has some vacation time coming up?

[QUOTE=joblack;177706]Let's get the next prime number.[/QUOTE]

I'm on it!

[quote=CRGreathouse;177709]Think Prime95 has some vacation time coming up?[/quote]

George can publish his vacation times so I can time my exponent endtimes ;)

[quote=T.Rex;177270]#cores = #threads. No Hyperthreading.
I don't remember about SSE2 or not. I guess not. I very quickly compiled Glucas, and was happy it works (self-test OK) fast. I'll go back to it later, next week. It seems now that there are more Nehalem available here. So, I'll try to get one from time to time for experimenting with Glucas and prime95. And Mlucas if you want. I simply hope that the compilation will be easier than on AIX/Power !
I didn't plan to be the first... I thought that my 16xNovaScale machine was now too old. I hope that you'll find time for fixing the problem with MLucas. Since Guillermo has no more time for maintaining Glucas, and since I am nuts about FFT, Mlucas seems to be the future, in // with prime95. However, I see that my old Itanium2 machine is still useful ! Different SW and different HW than prime95/PC.
I'm also very interested to understand the reason why Kevin's verification failed ! That's one of the good reasons why important companies cannot buy simple PCs for important stuff: they are not as reliable as are the big machines, like IBM Power or Sun SPARC.
Tony[/quote]

Can you tell us if you're Nehalem EX has 16 hyperthreaded cores. If yes have you tried prime95 with 16 threads and enabled hyperthreaded (should work faster in my estimation).

What mainboard did you use? How much memory? Can you (in the BIOS) overclock the machine?

[QUOTE=joblack;177723]...have you tried prime95 with 16 threads and enabled hyperthreaded (should work faster in my estimation).[/QUOTE]

It is unlikely that hyper threading will provide any benefit. Hyperthreading is beneficial when there are cycles lost waiting for main memory being brought into the cache.

With highly parallel code (like Mlucas & Glucas) the key is to have all data held within L2/L3 cache and never having to resort to main memory, thus removing any real benefit of hyperthreading.

For my run I used 8 CPU sockets of 4 cores each with two threads per core (64 threads). Performance was maximized by turning off the threads and the 2nd & 4th core on each CPU. This avoided any cache inefficiency.

It is worthy to note that scaling to a high thread count is very challenging. More threads does not necessarily mean more performance.

With Mlucas we can currently scale well to 16 threads but only at certain FFT lengths. I don't think Glucas has been taken past 16 threads either.

Feel free to speculate about Nehalem EX performance but at the moment neither Bull nor Sun have released NehalemEX based servers so anything we do know about their performance cannot be commented on due to non disclosure agreements.

Having said that I'm working furiously with Ernst to try get the Mlucas code working well for testing on Nehalem EP servers like the eight core [URL="http://www.sun.com/servers/x64/x4270/specs.xml"]Sun Fire X4270 Server[/URL] which I'll be able to release performance stats on.