Tracks order and threads

[grego mondo]

Hello

Using this home time to optimise my global architecture of workspaces

I'm trying to understand how to optimise theards and core calculation
I have a 4 core cpu (i7-3720QM) so 8 threads
I understood calculation goes thread 1 (tracks 1, 9, 17, 25 ...) thread 2 (tracks 2, 10, 18, 26, ...) ... thread 8 (tracks 8, 16, 24, ...)
Am I right ?

Let's imagine I have :
4 tracks for global remote, synch, master track, delay ...(let say track A, track B, track C and track D)
4 input tracks witch don't use simultanetly (I use track E or track F or track G or track H)
4 différents looper tracks witch don't use simultanetly (I use track I or track J or track K or track L)
4 différents sound generator tracks witch I can use simultanetly (let say track M, track N, track O and track P)

how should I set threads in set up ? (I setted 8 and not between 16 & 24 as told in the manual)
what order should I choose for my tracks ?
I added _ as empty tracks
I did
A E I B M N O P
C F J D _ _ _ _
_ G K _ _ _ _ _
_ H L

My thaught was to have :
all remote (not very CPU consuming but always playing) on the same threads here 1 & 4
Inputs (can be consuming but always one by one) on another threads 2
Loopers (can be consuming but always one by one) on another threads 3
Sound Generator consuming on separated threads 5, 6, 7 & 8


Am I far far away in another galaxy ?
Does it make sense ?
are you felling all right ?

thanks

[SylvainT]

Hello Grego,

It's a huge question, I try "une réponse de normand"

"I understood calculation goes thread 1 (tracks 1, 9, 17, 25 ...) thread 2 (tracks 2, 10, 18, 26, ...) ... thread 8 (tracks 8, 16, 24, ...)"

Where did you find those informations ?
In the manual, I can find that "Each rack is processed in a separate thread. Good values are from 16 to 32.". But nothing else.
I'm not really sure, but as I understand mutli-threading in Usine, (after many conversations with Senso), I think it is globaly impossible to anticipate the thread calculation. The command who needs to be calculated goes where it's free or wait for a free place.

To be continued ...

Sylvain

[SylvainT]

Hello Grego,

Ok, I cleaned up my mind about Usine and multi-threading. Thanks to Senso.
In fact you can't anticipate anything. No matter which is the order of your racks.
I'll try an explanation.
Usine uses multi-thread calculations for racks, so each rack is calculated by a thread. But you can't predict which thread will calculates which rack.
Let's say you have 32 threads available. It's more or less like if you have 32 guys waiting for a task (a job). For each Usine bloc, they choose a job and try to do it as fast as possible. When they have finished their job, they take another job if one is waiting or they have free time. So, you understand that if the 32 guys have more than 32 jobs to treat, they can (a priori) do it. They just need to finish all the jobs in around 3ms (if Usine bloc size is 128 at 44,1kHz).
So if you have a very heavy rack, you could have a problem, because it need more than 3ms to be calculated. In normal situations, everything's fine. And it's well done, the guys couldn't have two big jobs, one after the other, they can't finish in time.
There are some exceptions : if a rack goes in another, like a reverb, the guy who calculates the reverb needs to wait the guys who calculates the first rack.
Here's an important point : having heavy racks routed to one rack for FXs could generates problems. To avoid that, you need to use busses as they introduce one bloc latency. The guy who calculates the reverb receives the job treated one cycle before, so he doesn't "wait".

The best way to manage CPU consumption is to separate if possible big tasks on different racks. Then, be careful with rack to rack to rack to rack....
It's always a game between latency and CPU consumption.

Don't hesitate to dynamically switch on or off patches or subpatches if they don't need to be calculated.

Try to simplify your patches with less wires. Using Quick Links could be better to communicate with subpatches. Using arrays also, one wire with an array of 10 would be better than 10 wires in many situations.

Finally, avoid scripts for simple math which need to be calculated each bloc, especially with array. Scripts are very good for complex tasks, but it a long time job, so if they aren't calculated often, it's a good way. In simple task, not.

I hope it helps.

All the best

Sylvain

[x.iso]

oh, thanks for explanation, didn't know about buses introducing bloc latency. I think we need a CPU handling page in manual describing such behaviours of various components of Usine. for instance I'd like to know more situations where one or more bloc of latency is introduced and how that can be used to reduce CPU usage per bloc calculation time. How are modular wire connections treated for instance, same as buses? all of that would be great to have documented.

[SylvainT]

Everything is explained in the manual, but in different places. Maybe a special page with a global description is a good idea. I'll suggest to Senso.
For sure, buses, quicklinks, modular wires introduce one bloc latency, no more. Don't know about binds, I have to check.
One other thing introduce one bloc latency : on a rack, a patch 1 send information to a patch 2 who send new information to patch 1. Patch 1 couldn't be calculated without information from patch 2 who depends of patch 1. So the information from patch 2 is calculated one bloc later in patch 1.

All the best

Sylvain

Edit : binds introduced also one bloc latency

[x.iso]

yeah, I've seen it mentioned if latency added in a module in various places of the manual, but it's good to have CPU related page on this, so people understand what it means for CPU usage and DSP when block latency is added into calculations, and maybe some examples and strategies available to spread the load.
Also, maybe it would be a good suggestion to add option for racks such as "FX rack" so it basically adds 1 block latency and doesn't stack up calculation with source signal?

[grego mondo]

Thanks for that long answer (and the long thinking about it)

Good for that multi-threading thing, even if unpredictable, it's now understable for me (I thaught I remember that order thing form an olkd version, but my mind isn't has clean has my patches)

Yes I moslty (always) use on/off for patches (and subpatches) and Array to send values, I started using quick link also few time ago reading the documentation, I was also using more audio buses than rack to rack just as an instinctive way (looking more like hardware mixer to my mind)

Best to All

[SylvainT]

To x.iso

Also, maybe it would be a good suggestion to add option for racks such as "FX rack" so it basically adds 1 block latency and doesn't stack up calculation with source signal?

Use busses, no need for more option I think.

To Grego

Thanks for that long answer (and the long thinking about it)

You're welcome. It was good as well for me to clean up my thoughts. It's an important part of Usine to understand for advanced users, and it could be quite misty.

Last info on bloc latency for binds :
- bind buses introduce one bloc latency as they are an extension of bus.
- bind controls (ctrl-shift drag and drop a module on another) introduce also one bloc latency.

Sylvain

[damstraversaz]

that's a really interesting topic, thanks a lot