[QUOTE=ewmayer;140886]Whatever website you got the "Fortran" bit from is 10 years out of date.[/QUOTE]PrimeZilla was written in FORTRAN, but that was over 20 years ago.

[QUOTE=ixfd64;140882]George usually gives hints each time a Mersenne prime is reported. However, he didn't give us anything this time, other than an estimate on the completion date of the verification.

I think there are two reasons for this:

1. The new prime is smaller than 10 million digits, and George doesn't want us to be disappointed from the very start.
2. The new prime is larger than 10 million digits, and George wants it to be a surprise. :smile:

I'm betting it's the latter case. :smile:[/QUOTE]

3. The first time LL had a non-zero error code (I hope this isn't the truth)

TheJudger

[quote=ixfd64;140882]1. The new prime is smaller than 10 million digits, and George doesn't want us to be disappointed from the very start.[/quote]
Also because that would narrow it down to one exponent (there are three below the 10M digit threshold and two of those are doublechecks with matching residues, assuming those aren't fake).

[QUOTE=TheJudger;140890]3. The first time LL had a non-zero error code (I hope this isn't the truth)

TheJudger[/QUOTE]

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.

[QUOTE=ewmayer;140886]Whatever website you got the "Fortran" bit from is 10 years out of date.[/QUOTE]
From the Glucas web page as linked earlier by T.Rex:[quote]Glucas is a c-coded program to make Lucas-Lehmer test. As I have old Pentiums at home and work, I also included some assembler macros for GNU/gcc compiler to speed it up. I've reached about 80% of Woltman's latest prime95 v.20. For other platforms there is only two clients available fast enough, Glucas and Mlucas. Mlucas is an excellent fortran90-coded program written by E.W. Mayer (a version of Mlucas is included in the test suite specf2000). The performance of Mlucas is similar to Glucas. Mlucas needs a good f90 compiler and Glucas a C-compiler. For some platforms as Mac, there is no f90 compilers available, and here is the advantage of Glucas.[/quote]

[QUOTE=Anonymous;140897]From the Glucas web page as linked earlier by T.Rex:[/QUOTE]
Sounds like Guillermo hasn't updated his Glucas page in a while.

Anyway, why not use the [url=http://hogranch.com/mayer/README.html]Mlucas homepage[/url] to find out about the program? Would you go to the Microsoft website to find out about Apple products? ;)

[QUOTE=ewmayer;140898]Sounds like Guillermo hasn't updated his Glucas page in a while.

Anyway, why not use the [url=http://hogranch.com/mayer/README.html]Mlucas homepage[/url] to find out about the program? Would you go to the Microsoft website to find out about Apple products? ;)[/QUOTE]
Ah yes, thanks for the link, I didn't know where to find the Mlucas homepage before. I suppose I could have gotten there through the GIMPS freeware page, but I was busy with other things. :wink:

Edit: I checked the Mlucas page, but didn't see anything right off the bat that indicated any significant differences from Glucas, except that Mlucas uses its own FFT library whereas Glucas uses YEAFFT. Is one supposed to be faster than the other, or are they about the same?

[QUOTE=Anonymous;140899]Ah yes, thanks for the link, I didn't know where to find the Mlucas homepage before. I suppose I could have gotten there through the GIMPS freeware page, but I was busy with other things. :wink:

Edit: I checked the Mlucas page, but didn't see anything right off the bat that indicated any significant differences from Glucas, except that Mlucas uses its own FFT library whereas Glucas uses YEAFFT. Is one supposed to be faster than the other, or are they about the same?[/QUOTE]

YEAFFT is Guillermo's name for his *own* custom FFT. If I recall correctly he started by looking at the Mlucas FFT and then coded a similar algorithm, but with a very different coding style. since then the 2 programs have evolved separately, but the opcount to test a given exponent will be quite similar.

For single-threaded builds, the two programs run similarly fast. On the multithread front, performances seems to be in the same ballpark overall, but I suspect there will prove to be more disparities from platform to platform, because various platforms tend to "take to" coarse vs fine-grain parallelism quite differently, especially at higher thread counts.

Biggest difference, though, is yet to to come - Mlucas will soon have SSE2 support for x86 platforms. I already have a fully working version of this for Win32 using MSVC-style inline assembly [about 20000 lines' worth], currently porting the inline assembler macros to GCC syntax. It's a little slower than Prime95 clock-for-clock, but not embarrassingly so.

[b]Verification Update[/b]

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:

[i][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[/i]

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.

[QUOTE=ewmayer;140900]Also, on the Sparc alleged-new-Mersenne-prime verify front, we just got the keys to the proverbial Ferrari[/QUOTE]

That was Tom who absconded with the Ferrari ... and now it looks like Rob wants a piece of that action as well, I hear him revving up the "specially modified" Lamborghini out back in the Black-Ops garage... [more on that tomorrow, if the engine doesn't blow].

This is exhausting, but too much fun to miss.

[QUOTE=ewmayer;140900]YEAFFT is Guillermo's name for his *own* custom FFT. If I recall correctly he started by looking at the Mlucas FFT and then coded a similar algorithm, but with a very different coding style. since then the 2 programs have evolved separately, but the opcount to test a given exponent will be quite similar.

For single-threaded builds, the two programs run similarly fast. On the multithread front, performances seems to be in the same ballpark overall, but I suspect there will prove to be more disparities from platform to platform, because various platforms tend to "take to" coarse vs fine-grain parallelism quite differently, especially at higher thread counts.

Biggest difference, though, is yet to to come - Mlucas will soon have SSE2 support for x86 platforms. I already have a fully working version of this for Win32 using MSVC-style inline assembly [about 20000 lines' worth], currently porting the inline assembler macros to GCC syntax. It's a little slower than Prime95 clock-for-clock, but not embarrassingly so.[/QUOTE]Ah, I get it now. Thanks for clearing that up for me. :smile:

[QUOTE=T.Rex;140852]
And NO, I'll not say a word about the number of sec/iter I have. [U]It is obscene ![/U] And that would help to find the exponent of this 45th Mersenne prime (if proved). I'll provide it after.
[/QUOTE]

I see you've learned from last time. But it wasn't that offensive a question, was it?

[QUOTE=jrk;140892]Also because that would narrow it down to one exponent (there are three below the 10M digit threshold and two of those are doublechecks with matching residues, assuming those aren't fake).[/QUOTE]

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

Now for a stupid question... Can someone please post the FFT boundaries for the various programs and the relative iteration times at different FFT lengths for a fixed computer?