Build 3 available. Fixes pepi's problem with PRP of non-Mersenne numbers.

[QUOTE=Prime95;589597]Build 3 available. Fixes pepi's problem with PRP of non-Mersenne numbers.[/QUOTE]


Build3 working perfect
Thanks!

Build 3 solved partially my windows11pro performance issues.

But it is still slower when I stop and restart Prime95.

If I do a fresh boot up of my machine it gives around 2,850ms/iter.
But if I stop the task and restart it the performance goes down to 3,250ms/iter.

But at least it's better then the old 5,900ms/iter that I was getting on restart.

It is also known that win11 has some performance problems with Ryzen.
They're fixing it. Hope they can fix it.

I never had performance issues in windows10 with Prime95.

[UPDATE]: Performance bad again on a restart, around 5,750ms/iter

[QUOTE=JCoveiro;589753]But at least it's better then the old 5,900ms/iter that I was getting on restart.

It is also known that win11 has some performance problems with Ryzen.
They're fixing it. Hope they can fix it.[/QUOTE]
Does this issue only occur with the Ryzen CPUs, or there are similar delays for the Intel CPUs too.

Has Prime95 30.7 been tested on AMD Threadripper CPUs yet? Does Prime95 30.7 recognize the differences between the E and P cores of Intel 12900k?

It maybe a good idea to wait until the beginning of next year for me to buy a new PC, less troubleshooting and performance issues.

[QUOTE=Ben Delo;580497]Your wish is my command...

[CODE]
[Worker #1 Jun 10 01:33] Iteration: 410000 / 168308323 [0.24%], ms/iter: 2.386, ETA: 4d 15:15
[Worker #1 Jun 10 01:34] Iteration: 250000 / 168485323 [0.14%], ms/iter: 2.403, ETA: 4d 16:18
[Worker #1 Jun 10 01:34] Iteration: 160000 / 168548323 [0.09%], ms/iter: 2.409, ETA: 4d 16:39[/CODE][/QUOTE]
Ben Delo's AWS instance seems still somewhat faster than the top speed of Jcoveiro's PC.

Ben Delo's engine: 2.40 ms/iter
Jcoveiro's engine: 2.85 ms/iter

[QUOTE=tuckerkao;589791][...] Ryzen CPUs [...][/QUOTE]

There is an additional problem with Ryzen CPUs in Windows 11. The new scheduler has problems with the CPUs such that the L3 cache is used incorrectly (the calculations are correct, but data transfer is slower).

[QUOTE=tuckerkao;589791]Has Prime95 30.7 been tested on AMD Threadripper CPUs yet?[/QUOTE]

Yes, I am running ECM on one. Unfortunately, it is crashing and I am currently trying to reproduce it more reliably. It always generates an entry into the event log like:
[CODE]Error code: 0xc0000005
Error offset: 0x00000000020813bf[/CODE]
These numbers stay the same.

Edit: This is Zen 1 on Windows 10. Sorry for letting this out.

[QUOTE=kruoli;589796]
Yes, I am running ECM on one. Unfortunately, it is crashing and I am currently trying to reproduce it more reliably.[/QUOTE]

I doubt it has anything to do with Zen. Please tell me the worktodo.txt entry as well as the amount of memory ECM is allowed in stage 2. I'll start a run under the debugger and see what happens.

[B]Note to all:[/B] Until build 4 comes out, hyperthreaded torture tests must use the custom setting and select FFT sizes larger than 256K.

PM sent, thanks! :smile:

Would really like to have the option to specify get DC assigned via PrimeNet yet automatically run them as PRP DC/GEC/proof-gen on the prime95 v30.7bx client. Or to be able to specify getting PRP DC candidates & run them as PRP DC/GEC/proof-generation. Pig-in-a-poke generic DC as the only DC preference choice means LL DC may land on (newish) AVX512 hardware that's recently started throwing multiple Jacobi symbol check errors / DC exponent. I don't think forcing less-reliable hardware to either run first tests, or periodically produce sketchy LL DC, is the way we want to go.

[QUOTE=kriesel;589926]Would really like to have the option to specify get DC assigned via PrimeNet yet automatically run them as PRP DC/GEC/proof-gen on the prime95 v30.7bx client. Or to be able to specify getting PRP DC candidates & run them as PRP DC/GEC/proof-generation. Pig-in-a-poke generic DC as the only DC preference choice means LL DC may land on (newish) AVX512 hardware that's recently started throwing multiple Jacobi symbol check errors / DC exponent. I don't think forcing less-reliable hardware to either run first tests, or periodically produce sketchy LL DC, is the way we want to go.[/QUOTE]

Try work preference of 155. It's been there all along, probably never been tested.

[QUOTE=nordi;589277]I noticed that for ECM on small exponents, stage 2 init now takes a lot longer than before.[/QUOTE]

Computing better pairing is expensive. For large exponents this is well worth the cost as each multiplication saved is expensive. For small exponents such as yours saving a squaring is not worth terribly much. Consequently, for small exponents don't expect to see much, if any, improvement from the better prime pairing.

Prime95 does factor all this into account but only for the "common" cases. Common is defined as B1 between 10K and 100M, B2/B1 between 20 and 200.

Have you considered using GMP-ECM for stage 2? It should be superior for exponents up to 50K or so.