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: [url]ftp://mersenne.org/gimps/p95v284.win64.zip[/url]
Linux 64-bit: [url]ftp://mersenne.org/gimps/p95v284.linux64.tar.gz[/url]
Mac OS X: [url]ftp://mersenne.org/gimps/p95v284.MacOSX.zip[/url]
FreeBSD 10 64-bit: [url]ftp://mersenne.org/gimps/p95v284.FreeBSD10.tar.gz[/url]
Windows 32-bit: [url]ftp://mersenne.org/gimps/p95v284.win32.zip[/url]
Source: [url]ftp://mersenne.org/gimps/p95v284.source.zip[/url]

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

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.

Thanks! Will upgrade :smile:

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

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

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%]
[/CODE]

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.

[QUOTE=Prime95;367819]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%]
[/CODE]

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.[/QUOTE]

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

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[/code]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[/code]Also, please respect the system settings for date and time formatting: "Feb 25" vs "2014-Feb-25" and "13:43" vs "1:43 PM".

[QUOTE=retina;367823]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[/code]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[/code]Also, please respect the system settings for date and time formatting: "Feb 25" vs "2014-Feb-25" and "13:43" vs "1:43 PM".[/QUOTE]

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 [B]expected completion dates[/B].
[Worker thread #1]
M43112609, Lucas-Lehmer test, Sat May 03 23:48 2014[/QUOTE]
:blahblah: 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=kracker;367820]Would "Roundoff" or something like that work?[/QUOTE]

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

:all:

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.