how to set a thread to run at specific core

1. is it possible to set a thread to run at specific core.
2. to find number of core using vb.net

Answer this question

how to set a thread to run at specific core

viliescu
So, you'd rather cut the speed of the OS in half and have one core sit there idle Sure, it's great to say I want a process to use more processor, but by doing what you've suggested you'll make EVERYTHING slower. The OS will schedule a thread for a particular CPU/core, if it finds another that's better at a certain point of time it will switch it. If you tell the OS that only one processor/cpu can be used for a particular thread/process (OS/service/driver/etc.) then it can't automatically switch it for you and therefore everything runs slower.
Stephen912
Windows can only assign a CPU to a thread. That thread must exist within a process; but, if that process only has one thread then windows can give that process use of more than one CPU.

Regardless, an application can't know when a CPU will or will not be "usable". Setting thread affinity means telling the OS that certain CPUs should never be used (you're not simply telling the Windows to assign a thread to a CPU, you're telling windows what CPUs a thread CAN use). So, as a result, if you force your thread to a specific CPU and Windows decides that CPU should be used by another process for something else, extremely intensive, then your thread may be blocked despite a perfectly good and unused CPU being available. You have to be cooperative with all the dozens of other processes on the system...
luca90

BeginThreadAffinity will keep a thread on the same core/process for a specific duration. But there's nothing in .NET to specifically set the affinity of a thread to a specific core/processor.

What are you attempting to do
zbethem

Using the WinApi it's possible to edit your process afinity mask and to resume threads. However this can actually have highly detrimental effect depending upon the the nature of your application. Windows normally tries to keep a thread running on the processor which initiated it. Afterall, that process is in cache and will be faster rather than to have to do another cache loading on another core. It would be the rare thread that could accomplish anything meaningful with hard affinity unless it was specifically designed to do so.

Microsoft recommends the it's better to manipulate processor priorities in order to get achieve the process time you need. Other processes/threads will round-robin under you when you are at elevated priorities and surrender the processor. What Microsoft has to say in these regards really makes sense once you think about it.

To answer your other question:

System.Environment.ProcessorCount() will return an integer processor count. A single hyperthreaded processor is counted as two processors by XP.
Ayhan Yerli &#40;TR-NL&#41;

I agree with Peter. It would be nice if a cpu/OS marriage knew everything and could balanace everything perfectly but they aren't telepathic and peter is right on about the expense of the affinity assignment. It's also true that a cpu has memory caching which must be taken into account. What you want to do will momentarily invalidate memory caching and that too is expensive.

I don't believe that you've taken the full complexity of the what the processor and OS has to do, into account.
hawash

So You have the other core to run other things with......
Jon M.

He is referring to processor affinity in symmetric multi-processing configurations (SMP).

Please see System.Threading.Thread.BeginThreadAffinity() and System.Threading.Thread.EndThreadAffinity() in your object browser.

I hope this helps.

HillBillyB

Peter Ritchie wrote:
So, you'd rather cut the speed of the OS in half and have one core sit there idle Sure, it's great to say I want a process to use more processor, but by doing what you've suggested you'll make EVERYTHING slower. The OS will schedule a thread for a particular CPU/core, if it finds another that's better at a certain point of time it will switch it. If you tell the OS that only one processor/cpu can be used for a particular thread/process (OS/service/driver/etc.) then it can't automatically switch it for you and therefore everything runs slower.

I don't think that how the OS (for winxp) works . I running dual cpu for years (5 years) and tested my idea before making this suggestion . I don't know how u think OS(winxp) manage is multi core environment. but for me they don't work like u claim. form what i see ,this is how they work . if u have 2 cpu , os will label them cpu0 and cpu1 . default OS will run any app/service on cpu1 (not cpu0 , I don't know why). unless cpu1 full then it go to cpu 0 . The OS work from last to first .

for what u claim that it will run slower , i can say 100% wrong . even on 1cpu machine OS only take few percent. by assign OS to take 1 cpu can also increase security . this way in future when 4 core come out , we can set
Core1 --- OS
core2 --- service
core3 & 4 -- user app
this way antivirus or firewall app can have better performance .

for the priority option u mention, in multi core I guess it better change from priority of a system to priority of a core . mean each core can set it own priority on which thread or app that running in it.

boston123
truth . but in future with more core in one pc , it is important to have such function in a program. this way I can assign win os/service to take first core only and any others app in another and if anything wrong with app , it won't crash whole system cause the OS is at different core and we won't see windows act like hang due to app take too much resource.

avinashraj

Peter Ritchie wrote:
charles C wrote:
thks for all of your reply.

i found that even though a program is multi thread. but when it run under xp it always endup run on 1 cpu (unless the cpu is overload then it will assign to another) . but because of that the program run very slow . for example a program run 2 thread. each will take about 40% of CPU. if I don't manually assign each thread run on different cpu, it will endup both run on 1 cpu.
The OS has a very complicated method of assigning processors to threads. Although it doesn't take into account what may happen after it does assign a process to a thread (e.g. it may be when the thread is assigned to processor B its usage is 20% while processor B is at 80%--it could very well be by the time the thread starts executing processor B is now 80% and process or A is 20%). Although an application programmer can modify thread affinity (in the case of .NET 1.x/2.0/3.0, through Pinvoke) it is very expensive

The OS does it while it's running kernel mode code--when an application does it has to perform an expensive user-mode to kernel-mode context switch for the setting to occur, plus the various user-mode to kernel-mode switches to get the information (like performance counters) to make some "informed" decision. The OS can take into account trends in threads from other applications; an application can't.

It's just pointless to let anything other than the OS assign thread affinity.

what u said it maybe right, but this is if the OS cleaver enough to decide . for winxp they don't.
for example on a pentium3 dual cpu machine. just run some small program that will eat up 30% . u will see that only one cpu is fillup . if u try to run another that eat 90% cpu. window will still assign it on 1 cpu . so u will see 1 cpu full but others empty (cpu1 is 100% , cpu2 is 0%). too see the effect try run a video files (with very high quality encode in mkv) . u will see some effect of frame skip or sound get ansync . but if u manual assign those small program (that eat 30%) to second CPU , the video u play on first cpu will play without problem (cause it will only eat 90%) (cpu1 is 90% , cpu2 is 30%) .
now u see the important to assign thread to cpu. there's now way OS know how many resource a program need but the programmer of the program know.

Rob Swofford

charles C wrote:
I don't think that how the OS (for winxp) works . I running dual cpu for years (5 years) and tested my idea before making this suggestion . I don't know how u think OS(winxp) manage is multi core environment. but for me they don't work like u claim. form what i see ,this is how they work . if u have 2 cpu , os will label them cpu0 and cpu1 . default OS will run any app/service on cpu1 (not cpu0 , I don't know why). unless cpu1 full then it go to cpu 0 . The OS work from last to first .

I didn't say anything about what order it chooses CPUs/Cores. The rest of your comment agrees with what I said...

charles C wrote:
for what u claim that it will run slower , i can say 100% wrong . even on 1cpu machine OS only take few percent. by assign OS to take 1 cpu can also increase security . this way in future when 4 core come out , we can set
Core1 --- OS
core2 --- service
core3 & 4 -- user app
this way antivirus or firewall app can have better performance .

for the priority option u mention, in multi core I guess it better change from priority of a system to priority of a core . mean each core can set it own priority on which thread or app that running in it.

In your limited test you might see performance improvements in a single application. When you start using other applications (like Word, Outlook, Firefox, Acrobat, etc) your performance will start to fall apart.

Clearly you don't want to accept what the documentation states, so you've already made your conclusion (resulting in having your answer). So, I'll go ahead and lock this thread...

KAllbritain

charles C wrote:
thks for all of your reply.

i found that even though a program is multi thread. but when it run under xp it always endup run on 1 cpu (unless the cpu is overload then it will assign to another) . but because of that the program run very slow . for example a program run 2 thread. each will take about 40% of CPU. if I don't manually assign each thread run on different cpu, it will endup both run on 1 cpu.

The OS has a very complicated method of assigning processors to threads. Although it doesn't take into account what may happen after it does assign a process to a thread (e.g. it may be when the thread is assigned to processor B its usage is 20% while processor B is at 80%--it could very well be by the time the thread starts executing processor B is now 80% and process or A is 20%). Although an application programmer can modify thread affinity (in the case of .NET 1.x/2.0/3.0, through Pinvoke) it is very expensive

The OS does it while it's running kernel mode code--when an application does it has to perform an expensive user-mode to kernel-mode context switch for the setting to occur, plus the various user-mode to kernel-mode switches to get the information (like performance counters) to make some "informed" decision. The OS can take into account trends in threads from other applications; an application can't.

It's just pointless to let anything other than the OS assign thread affinity.

leozworld
sorry, what do you mean by core
meddy
thks for all of your reply.

i found that even though a program is multi thread. but when it run under xp it always endup run on 1 cpu (unless the cpu is overload then it will assign to another) . but because of that the program run very slow . for example a program run 2 thread. each will take about 40% of CPU. if I don't manually assign each thread run on different cpu, it will endup both run on 1 cpu.
how to set a thread to run at specific core

Answer this question