Prime95 defaults - your input requested
 

In the next version of prime95 I'm toying with 2 changes in its default behavior:

1) If you select a work preference of 100M, then prime95 changes number-of-workers and multi-threading so that each LL test runs with 4 cores (or all cores if there aren't 4 cores). You would not be able to override this from the menus, but perhaps you could from editing the prime.txt and local.txt.

2) When you first install prime95, it defaults to fewer worker threads and 4 cores per test. This is about 2.5% less throughput (measured on 4M FFT on my new Skylake), but newbies might not lose interest or be more inclined to stick around to complete at least one test. Over time, this would greatly reduce the number of exponents handed out to churners.

Comments? Improvements?


Other related ideas: A) Don't allow increasing number of workers if hours-per-day is less than 24. B) After completing 2 DCs in a default setup, auto-switch to multiple single-threaded workers to get back the 2.5% throughput loss.

As part of #1, can you build in something, so that when a user changes the workers, Prime95 will rework the worktodo file to keep all of the current assignments, but redistribute them to the current number of workers?

I like B.

[QUOTE=Uncwilly;429820]As part of #1, can you build in something, so that when a user changes the workers, Prime95 will rework the worktodo file to keep all of the current assignments, but redistribute them to the current number of workers?

I like B.[/QUOTE]
I second these remarks. :smile:

A few more things (of would be nice variety):

- Stagger threads on Windows by default, and set affinity to prevent threads jumping from core to core.

- By default, start utilizing cores from last to first, so that the first thread is left for the operating system for as long as possible. In other words, if the user selects fewer possible threads than physical cores available, then the numerically lower cores would be left free, rather than last cores.

- There is discrepancy between cores-threads during benchmark tests and during actual runs, if non-standard AffinintyScramble2 is set. I think benchmark tests should respect the AffinintyScramble2 setting. The counterargument is that this would cause better benchmarks results for those who set AffinintyScramble2 smartly over those who did not on the same hardware.

Thank you

[QUOTE=Prime95;429819]2) When you first install prime95, it defaults to fewer worker threads and 4 cores per test. This is about 2.5% less throughput (measured on 4M FFT on my new Skylake), but newbies might not lose interest or be more inclined to stick around to complete at least one test. Over time, this would greatly reduce the number of exponents handed out to churners.

Comments? Improvements?


Other related ideas: A) Don't allow increasing number of workers if hours-per-day is less than 24. B) After completing 2 DCs in a default setup, auto-switch to multiple single-threaded workers to get back the 2.5% throughput loss.[/QUOTE]

First I think starting with a single test is a fantastic idea :)

What happens with six core machines though? Would it run only one test with four worker threads, or two tests with three worker threads each?

I would leave the default setup of a single test until after the first completed LL test. I think the jump in processing time from two quick DC to 1/4th speed (on a quad core), slower LL may be discouraging.

1) Remove all capability of configuring workers & threads & affinities from GUI. Only show work types for LL (100M, WR, LL, DC). Use all available cores for the test.
2) Allow all the current behavior by directly manipulating prime.txt/local.txt.
3) There is no #3. Don't over complicate things.

#1 takes care of new users, and user who don't want the hassle of "choice". #2 gives the power back to power users to fine tune their configs.

Please don't complicate things with auto switch back and complex history-based adaptive behaviors and other fancy stuff. Forget the 2.5% efficiency. Keep it simple.

Regarding the 2.5% loss and the actual costs/benefits of trying to squeeze out that 2.5% from people that don't touch the defaults. If you lose more than 1 in 40 of the new participants due to their work becoming "boring" (because it takes so long to get a result) then all the effort to get an extra 2.5% is counterproductive and harmful to the overall progress rate.

[QUOTE=retina;429844]If you lose more than 1 in 40 of the new participants due to their work becoming "boring" (because it takes so long to get a result) then all the effort to get an extra 2.5% is counterproductive and harmful to the overall progress rate.[/QUOTE]

+1!

Also, it would likely be very confusing to a new participant who's worktype changes from DC to LL (after a couple of successful completions) to not only encounter much longer completion times because of the natural increase in the work involved, but the compounded with the (proposed) change in the number of workers for each.

[QUOTE=chalsall;429859]+1!

Also, it would likely be very confusing to a new participant who's worktype changes from DC to LL (after a couple of successful completions) to not only encounter much longer completion times because of the natural increase in the work involved, but the compounded with the (proposed) change in the number of workers for each.[/QUOTE]

I suggest there needs to be at least a basic communication (i.e. Pop-Up) that tells the user this is happening/happened.

I recall when I first joined a dozen or so years ago if I asked for a 10 Million Digit Number (yes 10) it gave some kind of a "Are you sure? This could take a long time." message.

If a new user asks for 100M digit it could say something to the effect:

"Based on your CPU specs this test will take at least 8 months to complete. Core assignments are being optimized to complete this test in 2 months."

Then later, once proven:

"Based on 2 (4?) good test results in the last 3 months your cores assignments can now be adjusted to complete more assignments though each in 8 months. Click YES to accept this change or KEEP to leave the assignments as they are."

OR....in some fashion at this point in time direct them to prime.txt and local.txt to do it manually

[QUOTE=Mark Rose;429840]
What happens with six core machines though? Would it run only one test with four worker threads, or two tests with three worker threads each?[/QUOTE]

Anyone with experience care to comment? I'm guessing two workers on three cores each would be best. How much throughput is lost running one worker on 6 cores?

[QUOTE=retina;429844]Regarding the 2.5% loss and the actual costs/benefits of trying to squeeze out that 2.5% from people that don't touch the defaults. If you lose more than 1 in 40 of the new participants due to their work becoming "boring" (because it takes so long to get a result) then all the effort to get an extra 2.5% is counterproductive and harmful to the overall progress rate.[/QUOTE]

You are probably right. I tend to over-optimize for throughput at the expense of the user experience.