[QUOTE=petrw1;182023]It has something to do with 32 bit registers. Above 64 bits the software has to use double the registers for each operation.[/QUOTE]

Yeah, I can understand the doubling part... but unless doubling the register makes a 2^2 increase in speed, I don't see how it becomes 4x faster and why this trend does not hold at higher bit levels.

Over 200...
 

201 P-1 completed ... 13 successes = about 6.5%.

[QUOTE=Primeinator;182009]How is it four times faster and what constitutes "low" bit levels? Is it not four times faster at higher bit levels? And 128-bit CPUs already exist... if you want to fork out the money to buy a server CPU.[/QUOTE]

Its four times faster cuz it does a 64 bit multiply into a 128 bit result in a single instruction. The 32 bit instructions needs to do 4 multiplies to do the same calculation.

At higher bit levels you can avoid some of the multiplies so its not a factor of four any more.

LL tests don't use the 64 bit nor the 32 bit integer multiply instructions. The Forier transforms use the floating point registers and floating point or SSE(2) instructions which are basically the same on both 32 bit and 64 bit machines.

Yes, if you had a cpu with a usable 128 bit multiply instruction it could be 4 times faster than 64 bits. But just because it is marketed as 128 cpu doesn't always mean it works right for this. You have to check the details.

I have recently swithced a single core on each of three dual-cores, and the first P-1 assignment just finished. It did not report results to the server and did not start the next P-1 assignment. I manually stopped/started the worker and it took off on the next assignment, but the completed exponent still did not report to the server.

This pc is running a 25.7 client with 512Mb allocated 24x7. Is this a known bug in 25.7 that was fixed in later versions?

There is no bug that I know of. Does prime.log shed any interesting light?

Please report the result manually using this web page [url]http://www.mersenne.org/manual_result/[/url]

Also check prime.txt to see that UsePrimenet=1 and ManualCommunication=0.

M51307721 reported it's NF-PM1 results to PRIMENET approx 5 hours after it completed, so, no need to report the result manually.

In prime.log there is nothing uneventful - mostly reporting on a daily basis, and, with M51307721 reporting 5 hours after it finished, the as-expected text with the amount of GHZ-days credit.

In prime.txt I see UsePrimenet=1, but I do not see ManualCommunication=0.

I will monitor the next completion/starting of exponents, and if the anomaly persists, I will upgrade to 25.9. I have two other cores that will start P-1 as current assignments complete, and will see how they perform.

That is one big @$$ factor....congrats...
 

David J. Stucki math-lab-b5 47193221 F-PM1 Nov 4 2009 2:54AM 3.6 1.3720 4655372538754486733614467124913690121322890046151
... 162 bits +/-

4655372538754486733614467124913690121322890046151
= 2 * 5^2 * 127 * 56099 * 1285993 * 47193221 * 141403499 * 1522815242222294233 + 1

What were the bounds on that? And how did it finish in 1.3720 GHz Days?

[QUOTE=petrw1;194755]David J. Stucki math-lab-b5 47193221 F-PM1 Nov 4 2009 2:54AM 3.6 1.3720 4655372538754486733614467124913690121322890046151
... 162 bits +/-[/QUOTE]

The factor is not prime:
4655372538754486733614467124913690121322890046151 = 29359077499843468232567 × 158566717185828044566850353

Apparently, this factorization was also found by the server as you'll see
if you check 47193221 in the Exponent Status.

[QUOTE=apocalypse;194760]And how did it finish in 1.3720 GHz Days?[/QUOTE]Found factor during stage 1? (guessing)
Normally you [url=http://mersenne-aries.sili.net/credit.php?worktype=P-1&exponent=47193221&factor=4655372538754486733614467124913690121322890046151]should get[/url] 3.0GHz-days credit for that result (I think? :huh:)