Prime95 version 26.2

[moebius]

Originally Posted by garo

Impressive speedup on my Corei5-750. Running four instances of 22Ms got the average speed from 18.5ms per iteration to 14.5ms per iteration.

Phenom X4 955 (K10) speedup running four instances 46Ms from 0.055 s to 0,050 s /iteration

Athlon 64 3700+ (K8) no noticeable speedup running one instance 46M from 0,113s /iteration

[paulunderwood]

Will these speed ups apply to future releases of LLR and PFGW for numbers such as 3*2^n-1 and Wagstaff?

[Prime95]

Originally Posted by paulunderwood

Will these speed ups apply to future releases of LLR and PFGW for numbers such as 3*2^n-1 and Wagstaff?

Yes.

[diep]

There is new dope!!!!!!!

GREAT WORK!

[Prime95]

Originally Posted by Mini-Geek

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 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).

The next release will offer 4 options (see undoc.txt).

0 = No messages
1 = displayed as part of the regular status line
2 = displayed in one line after the regular status line
3 = a multi-line output after the regular status line

[Prime95]

Originally Posted by TheJudger

On my systems 1 second is enough, depending what others say I would vote for a default of 2 or 3 seconds delay instead of 8 seconds.

I'll drop the default to 5 seconds

[Colt45ws]

Dropped LL iteration times .003-.005 on my i7 depending on factor size. But Im running with the SUM checking and round off checking since its heavily OC'd.
On my Core2 laptop it dropped at least a full .01 for LL of M53xxxxxx; dedicated P-1 thread taking 120 seconds less per .1% in stage 1 for another M53xxxxxx.
Experienced poor results on my K7. LL-D of M25xxxxxx took an additional .01 second per iteration. I think this was mainly due to it selecting a larger FFT size when 25.11 ran a test and went with a smaller FFT. Though I guess its obsolete so I didnt expect anything on it.
On my Atom running ECM another huge gain. 350 seconds faster per .08% than 25.11

[MarkAtHome]

Originally Posted by 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.

If you are open to a feature request, I would love to see options to launch an application if Prime95 indicates that a worker stopped and/or if an error is detected.

I normally launch Prime95, go into the living room, and find something else to do while Prime95 is working.

It would be helpful to know if one of the above errors occurs, so I can immediately (rather than when I find a moment to check on the PC) make system adjustments and then restart Prime95.

FWIW, I do the same when running Core Test. Under Options, Overheat Protection, Execute Program, I launch a DOS batch file (Win7x64) that repeatedly sounds an alarm loud enough to get my attention. I would like this option with Prime95, too, if possible.

Thanks!

[petrw1]

On four 40-41M LL tests iteration times dropped
- from 63 on core 0 and 60 or 61 on cores 1 - 3
- to 52-53 on core 0 and 50-51 on cores 0 - 3

A reduction of 20 or so percent

I also noticed the FFT dropped from 2560 to 2240 so it makes sense the iteration times should be faster.

I assume it's okay to change version mid-LL test? I've done so every previous upgrade but this is the first one to change FFT sizes mid test.

New question: Since the FFT dropped will the GhzDays credit also drop proportionally???

[petrw1]

Ok...maybe I should also report the offical benchmark results:

Prime95 64-bit version 25.9, RdtscTiming=1
Best time for 768K FFT length: 12.245 ms.
Best time for 896K FFT length: 15.290 ms.
Best time for 1024K FFT length: 16.974 ms.
Best time for 1280K FFT length: 21.723 ms.
Best time for 1536K FFT length: 26.305 ms.
Best time for 1792K FFT length: 32.092 ms.
Best time for 2048K FFT length: 35.395 ms.
Best time for 2560K FFT length: 47.010 ms.
Best time for 3072K FFT length: 56.634 ms.
Best time for 3584K FFT length: 69.052 ms.
Best time for 4096K FFT length: 77.440 ms.
Best time for 5120K FFT length: 99.858 ms.
Best time for 6144K FFT length: 118.041 ms.
Best time for 7168K FFT length: 145.307 ms.
Best time for 8192K FFT length: 156.573 ms.

Prime95 64-bit version 26.2, RdtscTiming=1
Best time for 768K FFT length: 10.362 ms., avg: 10.692 ms.
Best time for 896K FFT length: 12.742 ms., avg: 13.086 ms.
Best time for 1024K FFT length: 14.031 ms., avg: 14.353 ms.
Best time for 1280K FFT length: 17.998 ms., avg: 18.379 ms.
Best time for 1536K FFT length: 22.437 ms., avg: 23.038 ms.
Best time for 1792K FFT length: 27.542 ms., avg: 28.287 ms.
Best time for 2048K FFT length: 29.747 ms., avg: 30.440 ms.
Best time for 2560K FFT length: 37.392 ms., avg: 38.224 ms.
Best time for 3072K FFT length: 47.562 ms., avg: 48.426 ms.
Best time for 3584K FFT length: 56.659 ms., avg: 57.656 ms.
Best time for 4096K FFT length: 62.194 ms., avg: 63.343 ms.
Best time for 5120K FFT length: 79.415 ms., avg: 81.375 ms.
Best time for 6144K FFT length: 101.263 ms., avg: 101.581 ms.
Best time for 7168K FFT length: 120.439 ms., avg: 121.610 ms.
Best time for 8192K FFT length: 131.689 ms., avg: 132.365 ms.

Point of interest....on the benchmarks page on the V5 server the new entry still shows me at 25.9
... maybe it's becuase I ran the benchmark before I communicated my version change to the server because the Computer properties page didn't change until then.

[TimSorbet]

My old comparison was quite off, as hinted earlier by the retested small FFTs. The average single-threaded time decrease for my i5 isn't 5.42%, it's 18.13%.
I've rebenchmarked 25.11 and 26.2 on my i5 in even circumstances (I stopped PRPnet and ran both), and now I see that across the board, 26.2 is about 20% faster than 25.11 for both single- and multi-threaded work. Multi-threaded has a slightly better average speed increase than single-threaded, but is quite inconsistent on individual FFTs. E.g. single-threaded's worst time decrease was 7.02% and it's best 24.43%, and multi-threading's worst was a time increase of 50.00% and its best a time decrease of 67.25%. It's always possible this inconsistency was mostly/only due to the imperfect testing environment. I'm not sure, though.
1-thread avg. time decrease: 18.13%, 2: 19.87%, 3: 19.80%, 4: 20.01%.
Full results attached.

Note that I am now listing both "time decrease" and "speed increase" for the single-threaded results. What I had before called "x% faster" or "x% speed increase" was really (and is now called) a "time decrease of x%". The difference is usually somewhat minimal, e.g. a time decrease is 18.13% is a speed increase is 22.48% (in more extreme cases the difference is more pronounced, e.g. going from 2.000 ms to 1.000 ms would make a 50% time decrease but a 100% speed increase - it's just like going from 30 MPH up to 60 MPH, i.e. doubling the speed, let's you get places in half the time, e.g. 1 hr. down to 30 min.). Time decrease is calculated as ([old speed]-[new speed])/[old speed] and speed increase as ([old speed]-[new speed])/[new speed].