Some questions before I build my next computer

[dgatwood]

REAPER actually has some experimental modes to keep tracks locked to particular threads (and using thread affinity, to particular cores) for this purpose.. however on both my dual core laptop and on my dual quad xeon, letting the OS move things around actually performs significantly better..

Of course, I'm sure there are situations where it wouldn't, but I haven't tested all of the extremes.. but in quick and dirty real world testing, letting the OS decide was better...

Thread affinity only matters if the threads can do most of their work out of the L2 cache. If you had enough L2 cache to do all the audio processing without going out to RAM, thread affinity would make a big difference. Since L2 is getting blown out pretty much constantly anyway, I wouldn't expect it to help much.

If you really want to take advantage of thread affinity in an audio app, you'd need to use a CPU with a fully associative data cache and you'd need to model the cache usage of each plug-in, then block threads so that only a limited number can run concurrently on any core so that the audio data never gets blown out of the data cache. For arbitrary plug-ins, that would fall under the category of "really freaking hard".

And of course, the reason it ends up hurting rather than making no performance difference at all is that you're effectively preventing runnable code from being runnable by not allowing it to migrate to a different CPU, thus causing uneven loading on the CPUs since plug-in CPU utilization often varies significantly over time.

Besides, you don't want to lock it to a single core anyway. You want to lock it to a single CPU. They may do that, but if they're really locking it to a particular core, that's the wrong solution....