   Threads & cores - how do I force execution on a specific core
  On a PC, running Windows Vista...Let's supposed I create a thread in a C++ program to execute some code simultaneously to the main thread,  is there any way to 'force' this thread to execute on a particular core of the CPU ?   
  Check out MSDN - SetThreadAffinityMask Function;  In general this is a bad idea.  If you explain why you want to do this, someone else can probably explain why it's not going to end up with the result you want.   ;Quote:Original post by cache_hitIn general this is a bad idea.  If you explain why you want to do this, someone else can probably explain why it's not going to end up with the result you want.Basically, this.While forcing a thread onto a core might seem like a good idea (and on consoles is) on a multitasking preemptive OS its only going to end in pain. If you force something onto say core 2 and the OS decides to put work onto core 2 for something else as well then even if there are other idle cores around your work will be stalled out until the core becomes free again.This is the reason behind a lack of thread affinity in MS's recent Concurrency Runtime; you will get swapped out, so just go with it, because when you get back your cache will be trashed so its best not to worry.   ;Quote:If you force something onto say core 2 and the OS decides to put work onto core 2 for something else as well then even if there are other idle cores around your work will be stalled out until the core becomes free again.The OS won't bother putting work onto a busy core, when other cores are (relatively) idle. The OS will prefer to balance the load across all cores, which means avoiding the busiest ones.If all other cores are busy and the OS forces extra work onto that core anyway, then yes, it will stall your process - but if all cores are at 100% and the OS has something important to do, it'll stall your process regardless.There are of course better ways to get task-parallelism, but setting thread affinity isn't likely to pose any problems, as long as you don't accidentally affine to a core that's completely unavailable.Quote:This is the reason behind a lack of thread affinity in MS's recent Concurrency Runtime; you will get swapped out, so just go with it, because when you get back your cache will be trashed so its best not to worry.Isn't it possible that that's what the OP was trying to avoid cache trashes in the first place?OpenMP (unlike MSCR) lets you affine threads to cores, so that you can get the most out of cache-per-core CPUs like the AMD Phenom and the Intel Core i7. OpenMP is also cross-platform and astonishingly easy to use - you can even shoe-horn OpenMP 2.0 into VC++ Express 2008... but 2.0 doesn't have the affinity stuff.Still - for a realtime app or game, super-high performance probably isn't as important to the OP as smooth & consistent performance (even if no cores are ever pegged 100%), and for that, affining threads to cores probably wouldn't be as beneficial as plain old core-agnostic task parallelism, with a synchronisation barrier in the main thread.   ;  Thanks for the feedback!- I'm looking at writing some ray-tracing stuff on multi-core processors ( on PC )....   so performance is critical, and the algorithms are highly parallelisable...   it sounds like the OS is likely to hamper things though, it would be perfectly acceptable to lock out other tasks while it executes...  maybe there's some way of restricting the OS to use just a single core and free up the others, so that the cache doesn't get trashed by the OS....   time to do some googling methinks....cheers;  Afaik there isn't; the OS has the final word on hardware resource usage, I believe it is even free to ignore your thread affinity masks as they are just a suggestion as to what you would like it to do.As long as you aren't trying to run another heavy task at the same time then you'll get the vast majority of the CPU time anyway and if you are working on Vista or Windows 7 the scheduler is much better with regards to keeping your stuff on a single core between runs.End of the day however I'd forget about threads and instead use an existing task based system to dispatch the work which gets you automagic scaling.If you are using Visual Studio 2010 then MS's Concurrency Runtime is worth a look, as is Intel's Threading Building Blocks.   ;Quote:Original post by HelicobsterQuote:This is the reason behind a lack of thread affinity in MS's recent Concurrency Runtime; you will get swapped out, so just go with it, because when you get back your cache will be trashed so its best not to worry.Isn't it possible that that's what the OP was trying to avoid cache trashes in the first place?OpenMP (unlike MSCR) lets you affine threads to cores, so that you can get the most out of cache-per-core CPUs like the AMD Phenom and the Intel Core i7. OpenMP is also cross-platform and astonishingly easy to use - you can even shoe-horn OpenMP 2.0 into VC++ Express 2008... but 2.0 doesn't have the affinity stuff.Which was my point; you can't garentee that when you get back in, even if you have thread affinity set, that your cache will be remotely like it was when you left. (Source for quote below)Quote:ConcRT does some things to help with locality, but not exactly what you are expecting. The runtime does not affinitize individual ConcRT threads to a single processor each, but instead, affinitize them to a processor package or NUMA node. Since a process does not have exclusive access to cores (the operating system and other processes share cores with your process), you have to weigh the benefit of running a task on the same core after it was switched out and back in, against the opportunity cost of not executing that task on another core that happens to be idle. In addition, node affinitization helps with power management scenarios. On XP, we don't get topology information from the OS, but on Vista and higher, on a machine with 2 processor packages and 2 cores per package, a scheduler with MinConcurrency 2 and MaxConcurrency 2 will only use one package for executing tasks.;Quote:Original post by MarkVinceThanks for the feedback!- I'm looking at writing some ray-tracing stuff on multi-core processors ( on PC )....   so performance is critical, and the algorithms are highly parallelisable...   it sounds like the OS is likely to hamper things though, it would be perfectly acceptable to lock out other tasks while it executes...  maybe there's some way of restricting the OS to use just a single core and free up the others, so that the cache doesn't get trashed by the OS....   time to do some googling methinks....cheersWhy wouldn't you use something like Cuda, OpenCL, or DirectCompute (DX10 or DX11) for this if you are looking to develop highly parallel code.  GPUs have many, many more cores than the four on your i7's that operate in parallel.  Plus, I'm sure you really couldn't go wrong at this point by targeting at least one of the GPU-based programming languages.I pretty sure I've seen a realtime raytracing on the GPU.  Here's one quick example I found:  http://graphics.stanford.edu/papers/i3dkdtree/- Michael Tanczos   ;  OP: You should write algorithms that are core/cache/etc. oblivious and scale well. Optimizing for one specific hardware setup on PC is a quasi-guarantee that in the near future, your application will cripple through time, and all your work was meaningless.Quote:Original post by Michael TanczosQuote:Original post by MarkVinceThanks for the feedback!- I'm looking at writing some ray-tracing stuff on multi-core processors ( on PC )....   so performance is critical, and the algorithms are highly parallelisable...   it sounds like the OS is likely to hamper things though, it would be perfectly acceptable to lock out other tasks while it executes...  maybe there's some way of restricting the OS to use just a single core and free up the others, so that the cache doesn't get trashed by the OS....   time to do some googling methinks....cheersWhy wouldn't you use something like Cuda, OpenCL, or DirectCompute (DX10 or DX11) for this if you are looking to develop highly parallel code.  GPUs have many, many more cores than the four on your i7's that operate in parallel.  Plus, I'm sure you really couldn't go wrong at this point by targeting at least one of the GPU-based programming languages.I pretty sure I've seen a realtime raytracing on the GPU.  Here's one quick example I found:  http://graphics.stanford.edu/papers/i3dkdtree/- Michael TanczosThough industry strength ray tracing might not perform properly solely on the GPU ([0] [1]). Many interactive real time ray tracer have been developed solely on the CPU, most notably among hobbyists works are tbp's experimemts and Jacco Bikker's Arauna, and the seminal one with true ray tracing being Ingo Wald's (though it is outdated for some years already).   