More efficient to reduce worker count?

[petrw1]

Originally Posted by Mark Rose

I also have a 4770 and I have the same experience, with hyperthreading enabled.

3 cores slightly outperforms 4.

This seems odd but not impossible....the proof is in the pudding.

[CuriousKit]

Originally Posted by chalsall

Dual channel? As in, pair(s) of "sticks"? I assume so based on the amount of RAM you have, but it's an important variable.

Also, what speed?

Another thing which is absolutely critical in optimizing Prime95/mprime is to get the affinity correct. At least under Linux (mprime) I have found that without explicitly setting the affinity manually (via the AffinityScramble2 parameter in local.txt) the processes can often jump around, sometimes ending up with hyperthreaded "virtual" cores being used.

The 16 GB is split over four 4 GB RAM chips. I confess I don't know the brand or speed off the top of my head and will have to look inside to be sure.

I have noticed that Prime95 doesn't always know which logical CPUs apply to which core - sometimes it can work it out, but other times it can't, and just assumes 1 and 2 for core 1, 3 and 4 for core 2 etc (which is also what it determines upon working it out). My current settings are to use 4 worker threads, but with no multithreading (CPUs to use = 1). What would you recommend I set the affinity scramble to in order to ensure the worker threads stay out of the hyperthreaded virtual cores? Currently I've hacked it a bit by using Task Manager to uncheck what I assumed to be the hyperthreaded virtual cores in the process affinity for Prime95.

I figure I need to get a program that better identifies the CPU and its stats in order to make a more informed decision - any recommendations?

[chalsall]

Originally Posted by CuriousKit

I figure I need to get a program that better identifies the CPU and its stats in order to make a more informed decision - any recommendations?

No. You need many programs. Experiment. Test your theories. Rince. Repeat.

Test. Rerun tests. Then run again (changing only one variable).

Always amuse you are wrong.

[petrw1]

Originally Posted by chalsall

Always amuse you are wrong.

Freudian slip?

[kladner]

I see what you did there.

[chalsall]

Originally Posted by petrw1

Freudian slip?

Nope.

A true researcher must assume they might be wrong, but also that they might be correct...

And be prepared to answer the questions asked of them....

Cue the Monty Python "Run away, run away" skit....

[Mark Rose]

Assumptions often lead to amusement.

[CuriousKit]

I'm guessing that since Prime95 cannot reliably identify Windows CPU identifiers to individual cores, there isn't a single means of doing so. Experimentation seems like a good idea - I just wanted to avoid doing it unnecessarily if the answers are already published somewhere. I'll see what I find though.

Worst comes to the worst, I'll play around with the Windows API and the CPUID opcode myself!

[chalsall]

Originally Posted by CuriousKit

Worst comes to the worst, I'll play around with the Windows API and the CPUID opcode myself!

What this really comes down to is Prime95 / mprime doesn't actually optimize the CPU usage as well as was expected without human intervention.

No disrespect intended towards George.

But hand optimizing the affinity goes a really long way.

[Madpoo]

Originally Posted by CuriousKit

I'm guessing that since Prime95 cannot reliably identify Windows CPU identifiers to individual cores, there isn't a single means of doing so. Experimentation seems like a good idea - I just wanted to avoid doing it unnecessarily if the answers are already published somewhere. I'll see what I find though.

Worst comes to the worst, I'll play around with the Windows API and the CPUID opcode myself!

There is a way in Windows, and the Sysinternals program CoreInfo does a great job of showing how that works.

The method used to get the details hasn't always existed in Windows which is why, I assume, George didn't use that in the code. Seems to me that since it is there now, that should be the first option to figure it out and only if it's an older OS (Windows 2000 or something?) should it revert to the much cruder "timing method".

Ideally Prime95 would also simply exclude hyperthreads from consideration at all, pretending they don't exist when it comes time to setting how many workers a machine can have.

Anyway, the AffinityScramble2 I would use on a 4 physical core system is =02461357 ... your physical cores in Windows are going to be the 0246 and your HT cores are the 1357. You "map" those last so when you set the affinity for each of your four workers, you can just start with 0 then 1, 2 and 3 so they point to those first 4 cores you've mapped out.

Otherwise if you leave the affinity at 01234567 you have to remember to set each worker to have an Affinity that matches a physical core, like 0, 2, 4 and 6.

I guess either way you'd want to set an Affinity= entry on each worker, but what affinity you use depends on how you've mapped your cores.

Confusing? Yeah, probably... it could be made clearer or just handled in the code for the optimal settings, but leaving the option to override "just in case".

[CuriousKit]

No worries. It's something I need to pick up anyway, since my own programming is getting more advanced. Heck, maybe if I can get something consistent to work in regards to working out which logical CPUs map onto the same core, I can e-mail George with a proposed bit of code or something, or just post it on here somewhere. I don't know, whatever helps. In the meantime, I'll use the affinity override as suggested (yes, it is good to have a manual override no matter what, in cases where the automated method doesn't work for some reason, or if you want to deliberately override it to test something).