Prime95 version 26.2

[Prime95]

Version 26.2 is ready for beta testing. This is the first release of version 26, so it is probably best suited for the trail blazers among us. Personally, I am using this version for production work. I have not done extensive pounding on the user interface so there may well be bugs there.

Download links:
Windows: ftp://mersenne.org/gimps/p95v262.zip
Windows 64-bit: ftp://mersenne.org/gimps/p64v262.zip
Linux: ftp://mersenne.org/gimps/mprime262.tar.gz
Linux 64-bit: ftp://mersenne.org/gimps/mprime262-linux64.tar.gz
Mac OS X: ftp://mersenne.org/gimps/Prime95-MacOSX-262.zip
Source: ftp://mersenne.org/gimps/source262.zip

This release contains mainly performance improvements. There are some minor bug fixes and features too.

From the included whatsnew.txt file:

1) Faster FFTs for most SSE2-capable CPU architectures.
2) More FFT lengths supported.
3) Some of the new, faster FFTs don't let us do as much error checking on each iteration.
If you don't want to lose this error checking, choose "SUM(INPUTS) error checking" from
the Options menu. This will slow down your tests by about 2-5%.
4) When a possible hardware error occurs during a test, the error message would
likely scroll off the screen unnoticed. Now, all future progress updates to
the screen will be followed by a message containing a count of the errors that
have occurred during the test.
5) Worker Windows now stagger their starts. This improves timings for some
CPUs and operating systems. See undoc.txt to control this feature.

Bug fixes are described here: http://www.mersenneforum.org/showpos...57&postcount=2

[Prime95]

Known bugs and fixes:

1) The length 7K real FFT crashes on Core i3/i5/i7/i9 when running 32-bit Prime95 or 32-bit mprime. Fixed in next release.
2) Benchmarking on a multi-core or hyperthreaded machine resulted in several spurious "Setting affinity to run help thread..." messages. Fixed in 26.3.
3) The length 3072K (and some others) FFT crash on Northwood and Willamette Pentium 4. Fixed in 26.3.
4) The new feature that continuously outputs hardware error counts took multiple lines. Version 26.3 will have several undoc.txt options to control the amount of verbiage.
5) In rare situations, an insufficiently large FFT length was chosen. Generally, you would only notice this with larger bases. An example is 10024*603^153-1. Fixed in 26.3.
6) Worker-specific memory settings were not used in calculating the optimal P-1 bounds. Fixed in 26.3.
7) On 64-bit Ubuntu 10.x machines, trial factoring would find factors but would improperly format them for writing to results.txt and for sending to PrimeNet. Fixed in 26.3.
8) On 64-bit Ubuntu 10.x machines, N/A in worktodo.txt caused parse errors. Fixed in 26.3.

[joblack]

At least this link

http://mersenne.org/gimps/p64v262.zip

doesn't work.

[joblack]

Okay I got it from the ftp and just got a hardware error:

[Sep 15 01:27] Worker starting
[Sep 15 01:27] Setting affinity to run worker on any logical CPU.
[Sep 15 01:27] Setting affinity to run helper thread 1 on any logical CPU.
[Sep 15 01:28] Resuming primality test of M123456811 using Core2 type-3 FFT length 6720K, Pass1=1792, Pass2=3840, 2 threads
[Sep 15 01:28] Iteration: 80831503 / 123456811 [65.47%].
[Sep 15 01:28] Possible hardware errors have occurred during the test:
[Sep 15 01:28] 1 SUM(INPUTS) != SUM(OUTPUTS).
[Sep 15 01:28] Confidence in final result is fair.


Worked with the version before so I'm pretty confident that it isn't a hardware problem ... anyway maybe it's one of the new error checking methods.

[Prime95]

Originally Posted by joblack

Okay I got it from the ftp and just got a hardware error:

No, you didn't. You just ran into feature 4 described above. Prime95 is letting you know that you've had a SUM(INPUTS) != SUM(OUTPUTS) sometime during the entire LL test.

[joblack]

Originally Posted by Prime95

No, you didn't. You just ran into feature 4 described above. Prime95 is letting you know that you've had a SUM(INPUTS) != SUM(OUTPUTS) sometime during the entire LL test.

Great can I disable the hardware error output in almost every second line. I have recognized it ;). Btw. does that mean I should cancel the exponent or is it recoverable?

[Prime95]

Originally Posted by joblack

Great can I disable the hardware error output in almost every second line. I have recognized it ;). Btw. does that mean I should cancel the exponent or is it recoverable?

Yes, it can be disabled. See undoc.txt. Recommendations from y'all as to how to improve the feature (or if it should be deleted) are welcome.

As to the cancel question, I cannot answer that for you. Prime95 v25 did recover from that error. But did a hardware error get missed? Who knows.

[TimSorbet]

Prime95 crashes when it tries to run the 7K real FFT (there doesn't appear to be an all-complex 7K). It does the same thing whether trying to run it as part of the benchmark, or to test a number (whether as part of LL or P-1): Prime95 crashes immediately, and the Visual Studio just-in-time debugger pops up.
I'm on an i5 ("Optimizing for CPU architecture: Core i3/i5/i7/i9, L2 cache size: 256 KB, L3 cache size: 8 MB"), running on Windows XP (32-bit).
It's definitely consistent, not intermittent at all. I've tried 1K-8192K on real and complex FFTs, and only that one crashes. If you need more help from me to track down the problem, let me know what to do.
When running "AllBench=1" with the FFT at 7K, it crashed on the first test (maybe that helps, I suppose all those tests are using different backend techs...but I'd guess knowing that it chose the one for an i5 is sufficient to identify that).

So am I to understand that if I only use Prime95 fo stress-testing of a PC, this version is slower a little bit?

[TimSorbet]

Originally Posted by Octopuss

So am I to understand that if I only use Prime95 fo stress-testing of a PC, this version is slower a little bit?

No, they'll run the same or a little faster. But it doesn't really matter, since stress tests are more about maxing out the computer for a while to see if it makes a mistake, not seeing how quickly you can go through some number of iterations. When you run a Stress Test, it always fully checks for false results.

Originally Posted by Prime95

Recommendations from y'all as to how to improve the feature (or if it should be deleted) are welcome.

Would it be possible to basically anchor it at the bottom of the window (even if just by deleting the old message of it when you put it again) or put it in some special message box?
Or: Instead of making it take up 3 more lines, add it in-line with the iterations output. Or at least just make it 1 more line. e.g. go from:

[Sep 15 01:28] Iteration: 80831503 / 123456811 [65.47%].
[Sep 15 01:28] Possible hardware errors have occurred during the test:
[Sep 15 01:28] 1 SUM(INPUTS) != SUM(OUTPUTS).
[Sep 15 01:28] Confidence in final result is fair.

to:

[Sep 15 01:28] Iteration: 80831503 / 123456811 [65.47%].
[Sep 15 01:28] 1 error has occurred during the test, confidence in final result is fair, see results.txt

or:

[Sep 15 01:28] Iteration: 80831503 / 123456811 [65.47%]. 1 error detected in test, see results.txt

(As long as results.txt has more info on the error, saying it's SUM(INPUTS) != SUM(OUTPUTS) and the confidence in the final result is fair.)
Or put it, either on separate lines or in-line, after every x-th status instead of every status (e.g. put it on every 10th line, maybe configurable, so it stays visible most/all of the time, without having it spam every time).

Or make it so the user can somehow say "don't remind me of this particular error any more" (while still reminding me of other errors in this or other tests).

[joblack]

Does this release already include AMD optimizations?