That's a provocative title for a problem I've been facing for a long time.
 
It's a little hard to describe without an example.
 
I tend to build 'unnecessarily complex' Reaktor ensembles that take enormous CPU hits.
 
Reaktor is a single-core application and it will probably never be a multi-core app. 
 
So Reaktor does not benefit from multi-cores, just a very fast core.
 
If you need more, you will probably need to split Reaktor stuff into chains of parts and put them on tracks of a DAW.
 
But I have found that Sonar and Live both behave somewhat poorly in this regards (for me), maybe others get different results.
 
Assigning threads in a logical core whose paired other core is busy doing similar stuff seems to be the culprit - I feel a separate physical core should take preference.
 
I've found that using Reaper and telling it to use only Physical cores works very well. Turning off hyperthreading in BIOS also worked.
 
Here is a post in a Reaktor forum that describes the problem and highlights my concerns:
 
Managing Behemoths
 
I'm really hoping that somehow I may have misconfigured something on my computer so I'm asking for advice here from any more expert than me.
 

Skylake and Koby Lake (sp?) have acknowleged hyperthreading issues, but even allowing for that, HP have advised in previous generations of Xeon based servers to disable hperthreading for low latency operations (they're talking high performance SQL servers and the like of course) - that advice may have changed with i-series based Xeons though.

Is Hyperthreading bad for Audio?

Maybe it is for you in your particular situation.

Can't say I've seen a problem caused by it, but then I don't do what you do.

tlw
Is Hyperthreading bad for Audio?

Maybe it is for you in your particular situation.

Can't say I've seen a problem caused by it, but then I don't do what you do.

I can't say I've notice any issues on anything else I do, but I don't have any other things that are that stressful.
 

The better question is "is hyperthreading bad for Reaktor" and you answered that yourself. In general, audio is a linear process. The computer has to be quick enough to do all calculations of all plugins and other operations within the buffer time. But it can't "split the load" of a single plugin over multiple cores unless the plugin was written with multicore support and I'm not aware of any that are (iZotope solves this by splitting Ozone into separate plugins, when you need to). So if you keep increasing the required CPU power for a single plugin, yeah it will at some point crap out.

Sanderxpander
The better question is "is hyperthreading bad for Reaktor" and you answered that yourself. In general, audio is a linear process. The computer has to be quick enough to do all calculations of all plugins and other operations within the buffer time. But it can't "split the load" of a single plugin over multiple cores unless the plugin was written with multicore support and I'm not aware of any that are (iZotope solves this by splitting Ozone into separate plugins, when you need to). So if you keep increasing the required CPU power for a single plugin, yeah it will at some point crap out.

I changed the title.
That's not what I'm talking about.
I'm doing the splitting. I put multiple instances of Reaktor in multiple tracks.
What I'm talking about is the poor way DAWs select the core to run an instance of a VST.
 

Right, sorry, I misunderstood. I wonder if it matters that the plugins have identical names. Do you get the same behavior if you use a different DLL, like the 8 output version?

It may very well be because the DLLs and the ensembles running are the same code and that may have something to do with cache coherency or whatever.
 
Here is an example of what I did a few years ago. The results for Live and Reaper are still similar today. Sonar's results are better than what I saw then because of the new load balancing, but still not so good because that seems to increase the general overhead of Sonar across the cores.
 
http://www.arachnaut.net/...using%20two%20DAWs.pdf

I repeated those tests recently and someone suggested I try Reaper, so I downloaded it a few days ago and ran the tests again.
 
Reaper without any meddling gave me results similar to Live - Reaper chose to put my two ensembles in the same physical core and I got sound glitches. Sonar does not do that, it put them in separate physical cores. But the overhead for Sonar was much greater than Reaper or Live and that extra overhead defeated the gains of using the second physical core.
 
But when I disabled hyperthreading I saw this in Reaper:

I was able to load 4 instances without any problems. I did not test this using Live or Sonar (that is run the test with HT OFF), but I believe that would have worked just as well.
 
Telling Reaper to use Cores 1,3,5,7 with hyperthreading on also worked fine:

 
There's no way to set affinity for DLLs, just executables.
 
Of the three (Sonar Live Reaper) only Reaper with the cpu core locking capability was able to load balance the 4 instances of Reaktor that I used with HT ON.
 
Note that my CPU was running at 4.25 GHz to get that to happen.
My next audio system build may have 64 cores, but they may be locked at 2.8 GHz per core and will never get close to running this.
 
The most powerful supercomputer today uses a cluster of core running at near that speed - it will perform poorly on this test.
 

So in a nutshell, my tests tell me that a Reaktor builder will have to ensure that the ensemble they build never exceeds about 70% CPU at 2.8 GHz using today's DAWs.