Prime95 beta version 28.4

Prime95 · 2014-02-23, 22:01

Prime95 version 28.4 is available. This is not a release candidate, but should work OK. This version contains another performance tweak (compared to 28.3). It reduces the sin/cos constants stored in memory by computing the missing sin/cos constants at runtime. Thus, this version will in most cases be slightly slower running one worker and slightly faster running all workers (since almost all Intel CPUs since Sandy Bridge are memory bandwidth limited).

Running 4 workers, I'm seeing about a 1.5% speed boost on my Sandy Bridge and Haswell machines.

Download links:
Windows 64-bit: ftp://mersenne.org/gimps/p95v284.win64.zip
Linux 64-bit: ftp://mersenne.org/gimps/p95v284.linux64.tar.gz
Mac OS X: ftp://mersenne.org/gimps/p95v284.MacOSX.zip
FreeBSD 10 64-bit: ftp://mersenne.org/gimps/p95v284.FreeBSD10.tar.gz
Windows 32-bit: ftp://mersenne.org/gimps/p95v284.win32.zip
Source: ftp://mersenne.org/gimps/p95v284.source.zip

I have not yet addressed any of the feature requests, minor bug reports, or Linux GLIBC issues reported in the 28.3 thread.

Prime95 · 2014-02-23, 22:01

1. Option to make a noise if a PRP is found. Feature added to next release.
2. Option to scale "iterations between screen outputs" so that all worker windows output at roughly the same rate. Feature added to next release.
3. Option to update the worker window title more frequently than outputs to the worker window. Feature added to next release.
4. Per iteration screen output upgraded. It includes ETA. Classic output optionally available. Feature added to next release.
5. Benchmarking code updated. It now starts at 1024K. Multi-threaded benchmarks are now run only on the most useful combinations. For example, a quad-core hyperthreaded benchmark runs on 1 cpu, 1 cpu hyperthreaded, 2 cpus, 3 cpus, 4 cpus, and 4 cpus hyperthreaded. The trial factoring benchmark is not run by default.
6. Benchmarking also runs a multiple-worker test to measure memory bandwidth related degradation.
7. Many new undoc.txt options for benchmarking.
8. Centos 5.10 will be used to create future Linux executables. Hopefully this will help with reported GLIBC version number problems when building with Ubuntu 12.04.
9. Zero-padded non-base-2 AVX FFTs larger than 6K produced garbage for the roundoff error. Fixed in 28.5.

kracker · 2014-02-23, 22:15

Thanks! Will upgrade

pepi37 · 2014-02-23, 23:53

Updated on both OS. (Linux x64 and Win x64)

Chuck · 2014-02-24, 00:26

Thanks; updated on three machines. One won't make any difference (I7-970) but I did it anyway. Others are Sandy and Ivy.

Prime95 · 2014-02-26, 01:42

Anyone care to comment on proposed new screen output below? This is being implemented in response to the "Can you output ETA?" feature request.

Code:

[Feb 25 20:29] Resuming primality test of M54248741 using FFT length 2880K, Pass1=640, Pass2=4608
[Feb 25 20:29] Iteration: 698 / 54248741 [0.00%].
[Feb 25 20:29] Iteration: 720 / 54248741 [0.00%], roe: 0.156, ms/iter: 85.977, ETA: 53d 23:35
[Feb 25 20:29] Iteration: 810 / 54248741 [0.00%], roe: 0.188, ms/iter: 90.039, ETA: 56d 12:46
[Feb 25 20:29] Iteration: 900 / 54248741 [0.00%], roe: 0.188, ms/iter: 93.059, ETA: 58d 10:17
[Feb 25 20:30] Iteration: 990 / 54248741 [0.00%], roe: 0.189, ms/iter: 91.845, ETA: 57d 15:59
[Feb 25 20:30] Iteration: 1080 / 54248741 [0.00%], roe: 0.189, ms/iter: 91.062, ETA: 57d 04:11
[Feb 25 20:30] Iteration: 1170 / 54248741 [0.00%], roe: 0.189, ms/iter: 92.196, ETA: 57d 21:16
[Feb 25 20:30] Iteration: 1260 / 54248741 [0.00%], roe: 0.189, ms/iter: 91.669, ETA: 57d 13:20
[Feb 25 20:30] Stopping primality test of M54248741 at iteration 1270 [0.00%]

I originally used "error" instead of "roe" (short for round off error) because I thought the word error would be too scary for newbies. I could omit the round off error unless you set a prime.txt setting -- after all, it's not like cudalucas where the user should monitor this value.

Do you think the ETA bouncing all over the place is off-putting?

Oh, and once the ETA drops below 3 days prime95 switches to HH:MM:SS format.

kracker · 2014-02-26, 02:18

Quote:

Originally Posted by Prime95

Anyone care to comment on proposed new screen output below? This is being implemented in response to the "Can you output ETA?" feature request.

Code:

[Feb 25 20:29] Resuming primality test of M54248741 using FFT length 2880K, Pass1=640, Pass2=4608
[Feb 25 20:29] Iteration: 698 / 54248741 [0.00%].
[Feb 25 20:29] Iteration: 720 / 54248741 [0.00%], roe: 0.156, ms/iter: 85.977, ETA: 53d 23:35
[Feb 25 20:29] Iteration: 810 / 54248741 [0.00%], roe: 0.188, ms/iter: 90.039, ETA: 56d 12:46
[Feb 25 20:29] Iteration: 900 / 54248741 [0.00%], roe: 0.188, ms/iter: 93.059, ETA: 58d 10:17
[Feb 25 20:30] Iteration: 990 / 54248741 [0.00%], roe: 0.189, ms/iter: 91.845, ETA: 57d 15:59
[Feb 25 20:30] Iteration: 1080 / 54248741 [0.00%], roe: 0.189, ms/iter: 91.062, ETA: 57d 04:11
[Feb 25 20:30] Iteration: 1170 / 54248741 [0.00%], roe: 0.189, ms/iter: 92.196, ETA: 57d 21:16
[Feb 25 20:30] Iteration: 1260 / 54248741 [0.00%], roe: 0.189, ms/iter: 91.669, ETA: 57d 13:20
[Feb 25 20:30] Stopping primality test of M54248741 at iteration 1270 [0.00%]

I originally used "error" instead of "roe" (short for round off error) because I thought the word error would be too scary for newbies. I could omit the round off error unless you set a prime.txt setting -- after all, it's not like cudalucas where the user should monitor this value.

Do you think the ETA bouncing all over the place is off-putting?

Oh, and once the ETA drops below 3 days prime95 switches to HH:MM:SS format.

Hmm, maybe ms/iter ETA roe as format? Would "Roundoff" or something like that work?

retina · 2014-02-26, 02:48

ETA seems wrong to me. Estimated Time of Arrival? Instead I would like to see Estimated Date of Completion. eg.

Code:

[2014-Feb-25 20:29] Iteration: 720 / 54248741 [0.00%], roe: 0.156, ms/iter: 85.977, EDC: 2014-Jun-04

And then later when it is close to finishing: Estimated Time of Completion:

Code:

[2014-Jun-02 00:29] Iteration: 54248000 / 54248741 [99.99%], roe: 0.156, ms/iter: 85.977, ETC: 2014-Jun-04 13:43

Also, please respect the system settings for date and time formatting: "Feb 25" vs "2014-Feb-25" and "13:43" vs "1:43 PM".

TimSorbet · 2014-02-26, 03:23

Quote:

Originally Posted by retina

ETA seems wrong to me. Estimated Time of Arrival? Instead I would like to see Estimated Date of Completion. eg.

Code:

[2014-Feb-25 20:29] Iteration: 720 / 54248741 [0.00%], roe: 0.156, ms/iter: 85.977, EDC: 2014-Jun-04

And then later when it is close to finishing: Estimated Time of Completion:

Code:

[2014-Jun-02 00:29] Iteration: 54248000 / 54248741 [99.99%], roe: 0.156, ms/iter: 85.977, ETC: 2014-Jun-04 13:43

Also, please respect the system settings for date and time formatting: "Feb 25" vs "2014-Feb-25" and "13:43" vs "1:43 PM".

Only "ETA" is a common acronym for such a thing (AFAIK). Can also stand for "Estimated time approximately" or "Expected/Estimated Time to Achieve" according to some wikis I just read, which kinda work.
I think that, even if not strictly sensible when you consider it means "estimated time of arrival", "ETA" can colloquially be used in this sort of scenario, e.g. msieve uses it: "linear algebra at ...%, ETA 9h59m".
For the record, Prime95 uses language like the following in the Status window (emph. mine), which might suggest the acronym ECD:

Quote:

Below is a report on the work you have queued and any expected completion dates.
[Worker thread #1]
M43112609, Lucas-Lehmer test, Sat May 03 23:48 2014

If not "ETA", I think some other word(s) or abbreviation (e.g. "Est. time"), not an acronym, would be appropriate.
However, considering the Status window already shows you an ETA, and you can usually calculate an ETA from info printed on the screen, I personally wouldn't really want this in the first place. If it's an option I can disable and ignore, then fine (no harm done).

Quote:

Originally Posted by kracker

Would "Roundoff" or something like that work?

I like that better. Including this at all has newb-confusing/-scaring potential; maybe it should be an option that's disabled by default.

Xyzzy · 2014-02-26, 03:53

LaurV · 2014-02-26, 04:04

Mmmm! We love ETA's! (edit: or other versions, which retina claimed, they would perfectly work for us too)

Feature request: (fancy and not really necessary, but now the fashion is to request features) Can you put an option in some ini file about the number of iterations (or the passed time) used to compute the ETA? (the averaging period). Our computers do not run with the same speed always, and they are sometime stopped. We would like mainly 3 ways, one should be calculated from the actual speed, one from the speed of (say) last million iterations, and the third, considering the beginning time of the current exponent (this will start inaccurate, but it would get more accurate as the work is progressing).

:)

The format you shown is perfect for us.

2014-02-23, 22:01	#2
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 41·199 Posts	1. Option to make a noise if a PRP is found. Feature added to next release. 2. Option to scale "iterations between screen outputs" so that all worker windows output at roughly the same rate. Feature added to next release. 3. Option to update the worker window title more frequently than outputs to the worker window. Feature added to next release. 4. Per iteration screen output upgraded. It includes ETA. Classic output optionally available. Feature added to next release. 5. Benchmarking code updated. It now starts at 1024K. Multi-threaded benchmarks are now run only on the most useful combinations. For example, a quad-core hyperthreaded benchmark runs on 1 cpu, 1 cpu hyperthreaded, 2 cpus, 3 cpus, 4 cpus, and 4 cpus hyperthreaded. The trial factoring benchmark is not run by default. 6. Benchmarking also runs a multiple-worker test to measure memory bandwidth related degradation. 7. Many new undoc.txt options for benchmarking. 8. Centos 5.10 will be used to create future Linux executables. Hopefully this will help with reported GLIBC version number problems when building with Ubuntu 12.04. 9. Zero-padded non-base-2 AVX FFTs larger than 6K produced garbage for the roundoff error. Fixed in 28.5. Last fiddled with by Prime95 on 2014-03-07 at 15:37

2014-02-26, 02:48	#8
retina Undefined "The unspeakable one" Jun 2006 My evil lair 3·17·131 Posts	ETA seems wrong to me. Estimated Time of Arrival? Instead I would like to see Estimated Date of Completion. eg. Code: [2014-Feb-25 20:29] Iteration: 720 / 54248741 [0.00%], roe: 0.156, ms/iter: 85.977, EDC: 2014-Jun-04 And then later when it is close to finishing: Estimated Time of Completion: Code: [2014-Jun-02 00:29] Iteration: 54248000 / 54248741 [99.99%], roe: 0.156, ms/iter: 85.977, ETC: 2014-Jun-04 13:43 Also, please respect the system settings for date and time formatting: "Feb 25" vs "2014-Feb-25" and "13:43" vs "1:43 PM". Last fiddled with by retina on 2014-02-26 at 02:50

2014-02-26, 04:04	#11
LaurV Romulan Interpreter "name field" Jun 2011 Thailand 19×541 Posts	Mmmm! We love ETA's! (edit: or other versions, which retina claimed, they would perfectly work for us too) Feature request: (fancy and not really necessary, but now the fashion is to request features) Can you put an option in some ini file about the number of iterations (or the passed time) used to compute the ETA? (the averaging period). Our computers do not run with the same speed always, and they are sometime stopped. We would like mainly 3 ways, one should be calculated from the actual speed, one from the speed of (say) last million iterations, and the third, considering the beginning time of the current exponent (this will start inaccurate, but it would get more accurate as the work is progressing). :) The format you shown is perfect for us. Last fiddled with by LaurV on 2014-02-26 at 04:07

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
LLR beta Version 3.8.13 (deprecated)	Jean Penné	Software	111	2015-01-26 21:41
Prime95 beta version 28.3	Prime95	Software	68	2014-02-23 05:42
Prime95 version 27.1 early preview, not-even-close-to-beta release	Prime95	Software	126	2012-02-09 16:17
Beta version 24.12 available	Prime95	Software	33	2005-06-14 13:19
Beta version of PRP	Prime95	PSearch	15	2004-09-17 19:21

2014-02-23, 22:01	#1
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 41×199 Posts	Prime95 beta version 28.4 Prime95 version 28.4 is available. This is not a release candidate, but should work OK. This version contains another performance tweak (compared to 28.3). It reduces the sin/cos constants stored in memory by computing the missing sin/cos constants at runtime. Thus, this version will in most cases be slightly slower running one worker and slightly faster running all workers (since almost all Intel CPUs since Sandy Bridge are memory bandwidth limited). Running 4 workers, I'm seeing about a 1.5% speed boost on my Sandy Bridge and Haswell machines. Download links: Windows 64-bit: ftp://mersenne.org/gimps/p95v284.win64.zip Linux 64-bit: ftp://mersenne.org/gimps/p95v284.linux64.tar.gz Mac OS X: ftp://mersenne.org/gimps/p95v284.MacOSX.zip FreeBSD 10 64-bit: ftp://mersenne.org/gimps/p95v284.FreeBSD10.tar.gz Windows 32-bit: ftp://mersenne.org/gimps/p95v284.win32.zip Source: ftp://mersenne.org/gimps/p95v284.source.zip I have not yet addressed any of the feature requests, minor bug reports, or Linux GLIBC issues reported in the 28.3 thread. Last fiddled with by Prime95 on 2014-03-03 at 04:22

2014-02-23, 22:15	#3
kracker "Mr. Meeseeks" Jan 2012 California, USA 2⁷×17 Posts	Thanks! Will upgrade

2014-02-23, 23:53	#4
pepi37 Dec 2011 After milion nines:) 3·541 Posts	Updated on both OS. (Linux x64 and Win x64)

2014-02-24, 00:26	#5
Chuck May 2011 Orange Park, FL 1612₈ Posts	Thanks; updated on three machines. One won't make any difference (I7-970) but I did it anyway. Others are Sandy and Ivy.

2014-02-26, 03:53	#10
Xyzzy Aug 2002 2·7·13·47 Posts