Multi-Threading - Understanding

[sephult]

Hello All!

So I am looking into how multi-threading works at a deeper level.
I noticed some performance fallbacks not specifically in HollyHock, but in Cakewalk Sonar X3 recently.

This had me questioning handling of Multi-Threading, not just in the context of Sonar but in HollyHock.

So the setup was basically a few plugins and then Reaktor. In this setup I noticed Reaktor running at high CPU and at times peaking.
Upon inspection I noticed the first thread/core was being utilized highly while the worker threads were not balancing evenly.

I was just curious at more details in how HollyHock manages multi-threads and the balance of this?

This sparked many questions in how applications are developed and compatibility between multi-threaded versus single core applications. Seems that true multi-core/thread applications would start execution on the second core and leave the first alone for improved Single-core applications. Wouldn't you think that? I know that is a speculation beyond the details of the actual programming, but just a thought regarding. This started me into trying to understand the context of User Mode Scheduling...and so on.

Well just a ramble, curiosity, and ideas. Hope all is well for everyone.

-S

[sephult]

So in some research for SonarX3 I did find some options for scheduling profiles.
There were 3 options in which I was able to choose a different profile for an additional worker thread which was more specific to Quad+ core processors. In the same test I was able to decrease the load on the initial thread/core which allowed a lot more room for Reaktor to breathe without transient spikes causing drop-out. I am just very curious on how the implements of HollyHock and how other users utilize the MAX Number of Threads option in global settings as well as how it balances out, some Pro/Cons using these, and what other types of options and possible performance boosts we could give to our setup.

-S

[oli_lab]

I'm curious too in the kontak-hollyhock perspective.

[sephult]

Most definitely,

I have an intermediate to advance understanding of programming and computing, with not a lot of experience in direct from-scratch application. It's very interesting to me how things are currently handled and the future in regards to moving forward and handling. As in respects with Sonar, I can at least see some of the evolution of the multi-thread balancing, as I am still able to modify at least 3 parameters for comparison. So far I am not sure how the variations in threads and balancing works in HH.

Interesting enough, it makes me wonder when technology and programming practices start to allow more user mode scheduling and custom offloading to specify which cores or threads can be used more. In this application with using single core applications you would think that it would be extremely beneficial to be able to create a "Keep out area" which only lets you specify a few instruments to run on the core, while the balancing load is dynamic for multi-core use applications.

So Kontakt should already be optimized to use multi-core support, however you can specify in the settings the amount of cores you want to utilize. I guess in that perspective you would have to know more details on how NI utilizes the balance of the cores, then try to understand how Usine uses them respectively as well?

Unfortunately all I see about Reaktor is that it still is a Single-Core application, therefore when I load up other instruments in a "less-than-balanced DAW", (not saying in reference to Usine, but what I encountered in Sonar with my experiment)....Multi-core instruments still utilize the 1st Core quite a bit, leaving less room for "Single-Core" only applications.

This leads to my need to understand why computing and programming have not alleviated the usage and balance of custom-schedule cores/threads for high-performance applications like music and graphics.

I can accept, "it's just not there yet", just enjoy the discussion and like to understand more to help keep ideas in a good direction


-S

[gurulogic]

My very basic understanding is that in Hollyhock and most other multitrack DAW apps, CPU cores are assigned per track or "rack", so that essentially tracks 1-4 would utilize CPU cores 1-4. As far as threading goes I am less clear on how that works and how to find an optimal setting in Hollyhock for a specific setup. One approach I have used is to set up an identical CPU load on each rack (CPU intensive VSTI's) that maxes the CPU as close as possible to the point where I start getting dropouts etc and then try different number of threads settings until I find the best performance. But yes, it would be nice to have a more clear understanding of how to make these settings based on a specific usage environment.

[ahonoe]

gurulogic, I'd be interested in hearing more about what processor/thread settings you have had success with. I have a very processing intensive hh project (a multi-channel mixer/router) and I just bought a dual-processor system to support it.

[senso]

Basically HH assigns one thread per rack.
BUT if you create complex routings, ie several racks are sent to a reverb:
- the racks will be calculated in separate threads
- a the end (after all racks have been calculated), the reverb will be precessed alone in one thread.

Moreover, all devices are calculated in a single thread.
Finally, the order of calculation is, in our example:

- devices IN (1 thread)
- N racks (N thread)
- the reverb rack (1 thread)
- devices OUT (1 thread)


Also, remember that the system decides the assignation of CPU cores to threads with a very complex algorithm outside of this topic..

[ahonoe]

Thanks Olivier. Is a "thread" a "core"? Also on a system with multiple cores (12 in my case) does it make sense to increase the number of threads in hh?