Right-clicking a process in the details tab of taskmrg offers an “Affinity” listing of CPUs.
My Ryzen 5950x has 16 cores.
However, taskmgr’s affinity listing shows 32 cores (0 - 31).
I am guessing that I have some hyper-threading option enabled. If it is, I did not set it.
Assuming that having 32 cores appear on a 16 core system is related to hyper-threading, then what determines whether or not hyper-threading is enabled?
Is it a Windows setting or a BIOS setting, or some combination of both? Something else?
I would rather not have hyper-threading enabled, because (if I understand this stuff) single threaded programs will not get a full CPU – they will get ½ of one CPU. And there must be some processing power being used for managing the hyper-threading environment. Or have better minds than mine determined that it is best for hyper-threading to remain enabled?
You’re generally better leaving all cores enabled. Threads run on logical cores, so a single threaded application would only use one logical core anyway (there are rarely such things these days anyway as most compilers on modern systems will utilise some optimisations which will multi-thread some parts of any process).
Unless you have a specific, niche case to disable - leave enabled and then use affinity mask and process priority to manage applications on your system, if necessary to suit your needs.
Your CPU has 16 cores but 32 threads.
This might be a slightly disaccurate explanation but they increase the throughput of a processor basically by overcommiting system ressources.
This is a common practice nowadays. If you look into the virtual desktop and virtualisation area, lets say you have 100 users and give each user 4 cores (400 cores demand). But you only have 4 cpus with 16 cores each (64 cores supply). So: you overcommit cores. This works because it will likely never happen that all cores are used 100% at the same time. But everyone gets a speed benefit.
You can disable this feature in the Bios but I wouldn’t nessesairly recommend it.
My best guess is that you want to assign cores for plotting? What you can do simply is to assign the plotter to lets say 3 Physical cores. You assign 3 cores and the 3 corresponding hyperthreaded logical cores to the plotter.
You decide for example: core 5-15 (0-15)are for plotting, you choose the cores
10-31 in affinity. Leaving you with the following result:
Probably your limiting factor is the Temporary drive at this point. To utilize your cpu further, You may add more plotters on different temp drives to the set of logical processor units. Then you are fully utilizing your processor:
The processor performance sits at 92% but you still have 4 (!) pysical cores (8 logical cores) for other important task such as the chiaclient or what not. I currently run my rigs with a ryzen 5 3600. 6 cores are assigned to plotting, the other 2 for harvesting. So I don’t need to buy expensive Plotting gear.
Hardware info gives better info with the actual core numbers:
On my next re-boot, I am going to check my BIOS to see if hyper-threading is enabled. I see no reason to have that overhead.
I plot to two NVMe drives (neither one is my boot drive). Depending on the madmax phase, just one plot creation will run the CPU at 100% (phase 1 usually does that). But since I have two plotting jobs running, my CPU is almost always pinned or near 100% usage.
To ensure that the plotting is not interfering with any short, but important requests, I have both plotting jobs set to low priority. Even at low priority, they consume 100% CPU time and pound away on my NVMe drives. But I have the peace of mind knowing that they are using only idle time, and that all other system needs will not wait, including farming and harvesting, etc. I change only the plotting process priority.
I understand your suggestion of assigning cores. But then if cores 0-7 are assigned, but core 8 is not too busy, the plotting process will not be allowed to use #8. So I let Windows multitask and grab from whichever CPUs have idle time.
For my situation, I do not think that hyper-threading is helping. I will find out whenever I re-boot and start plotting again.
If you don’t fully understand what hyperthreading means, don’t mess with it. The overhead that you are afraid of (switching threads) is basically zilch for highly CPU intensive processing. Also, hyperthreading is hardware assisted thread switching to further minimize that overhead. On the other hand, in case one thread is starving for i/o access, the one that sits on a hyperthreaded core will jump in. Depending how the code is written, you can get up to around 30% increase in processing times.
Again, looks like you don’t understand thread priorities. By lowering it, you are not limiting thread processing capabilities, but rather letting the OS know that when there is a thread with a higher priority, such thread will have full access to the CPU, while the one with lowered priority will back off. On the other hand, if there is no other process with a higher priority, such lower priority process will get 100 CPU time.
As far as affinities, those are the best used when you have multi socket motherboard, and one CPU has better access to some memory, and drives, and the other has its own (faster access) memory drives (i.e., direct PCIe lines to those resources). On the other hand, trying to work with affinities on a single socket CPU is best done by process itself, and not that encouraged to modify by hand.
I wrote that I use low priority, not because it has anything to do with treads.
I wrote that I use low priority, because you wote:
So I pointed out my solution, and why it is my solution.
The above is also why I wrote why I use low priority, because it is my alternative to your suggestion on what you are doing. I do not have to worry about my harvesting, because it is set to normal priority. My low priority plotting has every core available, yet will not interfere with any other process that needs CPU time.
Using lower priorities to let the OS know to suppress MM is a good thing. One tick below normal will do the job. Lowering it further is not beneficial, as the lower you go, the more OS background tasks will be put in front of it, where chia processes run at normal priorities (thus one tick is enough).
As far as assigning cores, MM is the best written code for chia, and Max has really good understanding of threading system. Therefore, either specifying affinities or disabling hyperthreading should not be done (lower priority does exactly what is needed).
So, you are good, just don’t disable hyperthreading.
