Holy new Mersenne prime, Batman! (M47 related)

[jinydu]

Originally Posted by Kevin

I think after the last false-alarm, something was added so that if a prime was reported it would also send the error code (for whatever reason it didn't before). I imagine there would be far less optimism from all parties in the know if this were the case, and more to the point, I don't think George would've posted something on the main page if the test had an error and thus a non-trivial chance of being a false alarm.

Check page 3 of this thread.

Originally Posted by Prime95

Now it is very official. I have the last save file and I've rerun the last 5000+ iterations. Ahhhh, the pleasant beeping sound and repeating "New Mersenne Prime!!!" message.

[Kevin]

I'm aware of that. But an error that occurred before the last save file in some bizarre way that lead to a false positive would still lead to a false positive if you ran the last iterations again. As I already said, the optimism of George et. all in multiple statements are the best indications that there was no error.

[T.Rex]

Originally Posted by ewmayer

we just got the keys to the proverbial Ferrari

Can you describe the hardware of your Ferrari ?
Seems that my own Ferrari is a little bit slower than yours...
T.

[jrk]

Originally Posted by jinydu

Why do you say that? As I recall from looking at cleared.txt, all 18 candidates are first-time LL tests.

This is what I have in my cleared.txt from 0700 to 0800 23 Aug 2008 (sorted by latest first).

42796219  69     0x4F4C53A0908A5D__                23-Aug-08 07:59  DingoDog       starfury
21087943  67  D  0xC75D8B55B1D1B7__                23-Aug-08 07:58  DarekM         DAREKM20
42781927  69     0x8613884B69237A__                23-Aug-08 07:56  jmoseley       Vader
41935241  69     0xEDB167FA1DBB31__                23-Aug-08 07:53  S00039         Cinebox_0
41959849  69     0xD689BE98B86C77__                23-Aug-08 07:53  curtisc        grn206--11l
32428427  69     0xB6C80137FEDB7E__                23-Aug-08 07:49  suuuncon       SPDELL
42760397  70     0xA6090C299C0678__                23-Aug-08 07:46  curtisc        JCKL-ccd62L
42801739  69     0xF6DDB517B9A4C6__                23-Aug-08 07:44  DingoDog       starfury
28829407  69     0x849E58408C92DE__                23-Aug-08 07:41  hagenbuchner   XENserv1
20623513  67  D  0xF685AD4A0C9134__                23-Aug-08 07:35  WileECoyote    TimB21-1a
40896127  69     0x4F9CCA10FDF131__                23-Aug-08 07:35  fcg619         C1391
37763179  70     0xB141C151483C99__                23-Aug-08 07:34  curtisc        wcm128--03L
42206137  69     0x0A0EEC17151DAC__                23-Aug-08 07:33  drrocket       MIS5PC
43112609  69     0x8691696D2BDA50__                23-Aug-08 07:33  UclaMath       C20E3341C
36705287  70     0xDDA8BEB967041D__                23-Aug-08 07:32  dmazh          dm2
43411699  69     0x7C0112FE295ECD__                23-Aug-08 07:25  salfter        office1
38859463  69     0x5840B65CA7CB7B__                23-Aug-08 07:23  curtisc        JCKL-cce41L
43096799  69     0x32E28ECEC2C31B__                23-Aug-08 07:21  TeamRessler    1062315
37946213  69     0x901FF5AA04168E__                23-Aug-08 07:19  S611352        p4raid
19825909  67  D  0x6C5F679CF11DAD__                23-Aug-08 07:11  PennyBlkP      PennyBlk_S1
37425887  68     0x9B10891A72B405__                23-Aug-08 07:02  BranMuffin     ROTV-O4

32428427 was the one with the known fake residue, which is now known to be composite.

Of the candidates below 10M digits which occured before 32428428 (bolded above), two of them are doublechecks, and they have residues matching the first time checks, compared to older cleared.txt reports and the v5 server in this thread (again, assuming they haven't been faked to match, which I think is unlikely).

[jinydu]

I see. I copied my list of candidates from Fusion_power on post #123. He must have omitted the double-checks.

[ldesnogu]

Originally Posted by T.Rex

I'm using a 16x Itanium2 1.6 Ghz NUMA machine. And I've used some specific code and some special features of the Bull Linux version in order to have such a terrific speed.

What are those special Linux features, if you can say that is . hugetlb stuff? Others?

[rgiltrap]

Originally Posted by T.Rex

Can you describe the hardware of your Ferrari ?
Seems that my own Ferrari is a little bit slower than yours...
T.

I've held off giving much in the way of details as we have been running on some outdated hacked up version of Mlucas from last year which we hadn't really tested well at the current FFT length. As of today we have the nice new Mlucas code release working which means we have a bit more speed and a lot more reliability in terms of restart capability (just in case if anything goes pear shaped).

The system we have been using is a Sun SPARC Enterprise M5000 Server. These are a very popular Sun systems due to the impressive raw performance both in CPU and I/O.

Up until today we have been running on 8 (16 cores) * 2.15 GHz SPARC64 VI processors. From today with the new code and availability of a new system we are now able to continue the run on a M5000 with 4 (16 cores) * 2.4 GHz SPARC64 VII processors.

The systems are running Solaris 10, the Mlucas code was compiled with Sun Studio Express and parallelized using OpenMP.

The biggest pain as Ernst has pointed out is that we are running at an unnecessarily large FFT length of 4096K which means we have a significant performance deficit that we are still trying to resolve.

NB: The Mlucas code we are using is pure C with no special machine specific assembler code. This really highlights the amazing application design from Ernst and the OpenMP skills of Tom Harper (who worked on Mlucas during last years Google Summer of Code).

[rgiltrap]

Originally Posted by rgiltrap

Up until today we have been running on 8 (16 cores) * 2.15 GHz SPARC64 VI processors. From today with the new code and availability of a new system we are now able to continue the run on a M5000 with 4 (16 cores) * 2.4 GHz SPARC64 VII processors.

I should note that using Mlucas the maximum number of usable threads is currently 16, though Ernst has plans for that

I would love to throw 256 SPARC64 VII cores at it if we could use them . Then again I don't think anyone would loan me one of those!

[jinydu]

Just for reference, the smallest exponent for which Prime95 version 24.14 uses 4096K FFT is M68,130,000. So the fact that 4096K is unnecessarily large is of no use as a hint...

Originally Posted by ewmayer

But I strongly suspect both Prime95 and Glucas are using the same FFT length, because it should be ample for testing the number in question.

That on the other hand could be a clue. I'm guessing it means the exponent is not just barely above one of the Prime95 FFT boundaries.

[Batalov]

Originally Posted by rgiltrap

(just in case if anything goes pear shaped)..

I don't know about you, but I find nothing wrong with pear-shaped... thingies... Some of them are really useful ...for one thing or another...

[davieddy]

Originally Posted by ewmayer

Verification Update

Also, on the Sparc alleged-new-Mersenne-prime verify front, we just got the keys to the proverbial Ferrari: I have grayed out the iteration number, the other verifiers will be able to fill it in once they see a matching 64-bit residue for their own runs:

[Sep 04 04:30:19] Mxxxxxxxx Iter# = 2**00000 clocks = 00:26:06.000 [ 0.0224 sec/iter] Res64: 9A889EC66E9DB2DC. AvgMaxErr = 0.000001898. MaxErr = 0.00000381

So even though this is still at the wastefully long FFT length of 4096K, we are running as fast as Tony Reix's more-recently-started verify run.

0.0224 sec/iter means ten days for 40M iterations.
Taking this with the presumed inadequacy of a 2048K FFT,
I think we can anticipate an exponent > 40M.