]]>
- 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..
Statistics: Posted by senso — 16 Oct 2015, 08:47
]]>
]]>
]]>
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
Statistics: Posted by sephult — 17 Jan 2015, 19:31
]]>
]]>
-S
Statistics: Posted by sephult — 16 Jan 2015, 17:02
]]>
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
Statistics: Posted by sephult — 16 Jan 2015, 16:43
]]>