I have a program that I want to run on one core of a compute unit (say, core 5), while ensuring that its matching core (core 4) remains halted. That way the program gets full use of the compute unit's shared resources.
Whichever core I disable in this way, I can pin my test program to its matching core.
Any ideas how to do this?
That is not how processors work. A program gets full use of its resources all the time. Disabling a core is not going to improve that. Anyways... https://en.wikipedia.org/wiki/Processor_affinity
AMD processors also have no Hyper-threading, the pit falls involving that do not apply.
Thanks for answering.
Let me explain something about Bulldozer. A Compute Unit (CU) consists of two Cores which share some resources. Windows recognizes the cores separately, and can schedule work on them independently.
Due to the way that the CU resources are shared between its two cores, a program running in one core will get more work done if the other core is halted.
That's why I'd like to tell Windows (or the BIOS) not to use core 4, say, but treat the other 7 cores normally. My ASUS BIOS will let me lock out cores 6 and 7, or 4, 5, 6, and 7, but not just a single core.
In practice, I pin my test program to core 5 and run a profile on all 8 cores. I find that core 4 gets used slightly. I can live with that, but I'd prefer to have core 4 not get used at all.
EDIT: Another possible solution would be to tell Windows to dedicate a certain core to one particular thread. I could have that thread go into a permanent wait state, and presumably, Windows would halt the core while it is in that state, and not schedule any other thread to go there.
Last edited by MeepMeep; 31 Jul 2012 at 17:28. Reason: Add more info
Trying to disable the core will not do what you think it will do. It will not improve performance of your application in the slightest.
Agreed. Leave all cores enabled and allow the thread allocation logic on the CPU to dynamically assign cores to the program threads as it deems necessary. Due to the way that programs are designed, there will be certain threads (strands of execution) that are memory and/or cpu intensive, whereas others are not so demanding. It is because of this difference that you can sometimes see a dramatic difference in cpu core activity when running a program/application. There is nothing wrong with that, it is just how the individual cores have been allocated to the threads.
Well try to open Task manager .. select the program under process... right click and select "Set Affinity" and select the core you want the program to run,....
Hope this is what ur are looking for
I am pleased to see so many of you answering me. Thanks for that.
However, there's still a misunderstanding about what I want and why...
1. Setting an affinity for the program I am testing is only part of the deal. What I want to do is keep all other threads from using the same core.
2. The Bulldozer architecture really does have a penalty if two threads are running in the same CU, compared with the same threads running in different CUs. The major item is that the instruction decoding rate for a core is cut in half if the other core is running, as the shared decoder alternates between servicing the cores. If one core is halted, the other core gets the full bandwidth of the decoder.
I have seen comments somewhere that Microsoft is aware that this is a problem with Windows (i.e., treating all processors equally for scheduling purposes), and that there is something in the works to assign only one thread to each CU when possible. The same would apply to the two threads in an Intel core with hyper threading. Anyone know about this?
The hotfix for the Windows kernel that allows Win7 to "understand" compute units and treat the pairs properly when it comes to scheduling and core parking on a Bulldozer CPU is here:
An update is available for computers that have an AMD FX, an AMD Opteron 4200, or an AMD Opteron 6200 series processor installed and that are running Windows 7 or Windows Server 2008 R2
There's no need for hackery - just the kernel update from that hotfix.
Quote