On 10 April 2016, 19:53:20 UTC, PrimeGrid’s PPS Mega Prime Search project found the Mega Prime:

369*2^3365614+1

The prime is 1,013,154 digits long and enters Chris Caldwell's The Largest Known Primes Database ranked 155th overall.

The discovery was made by Will Steinbach (bill1024) of the United States using an Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz with 32GB RAM, running Linux. This computer took about 1 hour 36 minutes to complete the primality test using LLR. Will is a member of the Crunching@EVGA team.

The prime was verified on 10 April 2016, 20:58:16 UTC, by Stephen Norton (spnorton) of the United States using an Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz with 32GB RAM, running Microsoft Windows 7 Professional. This computer took about 2 hour 52 minutes to complete the primality test using LLR. Stephen is a member of the Alien Prime Cult team.

For more details, please see the official announcement.

I red that announcement to my wife.
She looked at me and said " Your such a geek." LOL

One thing I noticed is I have a E5-2670 I believe at 2.9ghz with turbo.
The doublec-hecker has a i7-4790 At 3.6ghz maybe faster with turbo.
My time was 1:36 vs their 2:52 I use Linux they used win7.
Must be the same WU, I am surprised Linux is that much faster.
It is around 1.25 hour difference, that's a huge difference.

There's a small difference between Linux and Windows, but usually it's simply that Windows runs a lot more crap in the background. With GPU apps, you'll often find Windows is actually faster because often the video drivers are better.

With CPU LLR or Genefer apps, NEVER use hyperthreading. The app will run at least twice as slow, which puts you at a huge disadvantage against the guy who isn't running with hyperthreading. (I bought an i5 specifically because of this. Why pay 50% more for the equivalent i7 when I'm never going to use hyperthreading? Take the $$$ and buy a better CPU cooler or video card or faster memory.)

But, by far, the biggest thing is the cache. Set it to 0 (or just barely above 0). You're competing against people who DO run with a 0 cache, and even if your computer is twice as fast as the other guy's, if the task sits on your computer for a day before it's started, the other guy is going to return the task first 9 times out of 10.

Bottom line: turn hyperthreading off and set the cache to zero, because you can bet the house that this is what your competition is doing. :)
____________
My lucky number is 75898⁵²⁴²⁸⁸+1
(I am NOT an administrator anymore, so please don't PM me with questions. I can't help.)

Michael your advices are really good, but...
I noticed that from one Boinc version behavior is changed, not a lot, but it changes ( and I was writing about that on this pages)
On short WU ( before) when you set cache to 0 then Boinc will download new task right before old task is finished and sent. That was OK.
On new version, Boinc start to download new task when 70% of old task is over. Maybe difference is little, but that small one give chance to wig-man to be faster ( AVX2 vs AVX...)

Someone here told me that behavior of Boinc cannot be changed and I must accept that change... of course there is always option to put back old Boinc version...

Look at this message as observation, not question that needs answer :)

____________
314187728^¹³¹⁰⁷²+1 GENERALIZED FERMAT :)
93*10^^1029523-1 REPDIGIT PRIME
31*332^³⁶⁷⁵⁶⁰+1 CRUS PRIME
Proud member of team Aggie The Pew. Go Aggie!

On Linux vs. Windows, in LLR testing there was no difference I could find between them in performance. Any I thought I did find could be explained by scheduler weirdness that went away once HT was off, and in that case Linux was worse.

Crun-chi, can you be more specific in versions of boinc with that behaviour? I'm running 7.6.22 on Windows, and that does the download just before WU finishes thing. This is the latest stable version. Is that behaviour in the latest dev version?

On Linux vs. Windows, in LLR testing there was no difference I could find between them in performance. Any I thought I did find could be explained by scheduler weirdness that went away once HT was off, and in that case Linux was worse.

Crun-chi, can you be more specific in versions of boinc with that behaviour? I'm running 7.6.22 on Windows, and that does the download just before WU finishes thing. This is the latest stable version. Is that behaviour in the latest dev version?

On the boinc thing? I lean towards shorter LLR units, up to TRP. Doesn't seem to make any difference what length the units are. New work is grabbed shortly before finishing.