Truls Becken - 2009-03-16 15:42 :
Christian Packmann wrote:Rene Gollent - 2009-03-16 14:47 :All it takes is a single busy higher priority thread getting scheduled on the same core and your careful tuning has gone out the window, since I guarantee that it will run faster if the scheduler is able to drop it onto an idle core on a different CPU than if it can't run at all, FSB latency or not.Finally, a sound technical reason against hard affinity. Thank you. Which only becomes a problem if you run two programs using hard affinity at the same time which try to use the same cores/threads. Otherwise the scheduler will push the non-bound threads on the idle cores.Doesn't this imply that threads that use hard affinity get higher priority than any thread that doesn't? Isn't this exactly the opposite of what you want for number crunching? The heavy lifting should run with low priority to avoid affecting system responsiveness.
Sorry, I wasn't clear. Of course I assume that those threads will run at low priority. If they are competing with higher-pri threads on the same core, they'll get no/little time allocated. But even if you start your e.g. DC client while the core is busy with a higher-pri thread, the other thread will likely run only a short time - most user interactions don't last long in CPU time on modern systems. When the system has to do some user work again, it'll look for free cores/hw-threads first and schedule the user tasks there if possible. Otherwise they get scheduled on the bound cores/hw-threads and execute there, taking away time from your background program.
Christian
