Bitwig's cpu core allocation per track?

[Echoes in the Attic]

Does anyone know how exactly Bitwig dviides cpu core usage between tracks?
-Is it per track without regard for container devices?
-Is it one core per track, including instrument/audio tracks and effect tracks? So if you had 8 tracks and 4 effect tracks and 6 cores, it would allocate one core per track in the order of tracks? Or the order they are instantiated?
-Do plugins that use multiple cores have any effect? Or for that matter the relative usage of different cores?

[stamp]

Afaik it's one track per core and when using plugins that have multicore option such as u-he the load gets spread across multiple tracks. Regarding the difference between regular tracks and effects track I don't know but it's easy to test it yourself.

[Echoes in the Attic]

Afaik it's one track per core and when using plugins that have multicore option such as u-he the load gets spread across multiple tracks. Regarding the difference between regular tracks and effects track I don't know but it's easy to test it yourself.

Not really. Computer died and am spec'ing a new one.

[stamp]

Oh... that sucks. I will make some test tomorrow and report back.
Regarding your new pc my advice is to go at least with an 8 core cpu if you can afford it.

[Echoes in the Attic]

Oh... that sucks. I will make some test tomorrow and report back.
Regarding your new pc my advice is to go at least with an 8 core cpu if you can afford it.

Thanks. I'm thinking 6 core as it will be a fair bit cheaper and should do the trick.

So for example I'm wondering if I had a template of 8 tracks and 4 send effect tracks, how it would split it up? Would it have the first 6 tracks on cores 1-6 and then tracks 7 and 8 on the first two cores again and then the 4 effect tracks on cores 3-6? Is load per track irrelevant and it just goes by the order? There must be some logic, I just don't know what it is.

[sth]

It's a whole lot more complicated than this. Instead of Tracks as simple "parallel lanes" it's much better to imagine your whole Project as a "Directed Graph" like a Tree with the Master channel as the final node. Each Track is a Branch and they all "point downwards" towards the Root/Trunk/Ground/Master.

Each Track starts out as a separate Branch, and then all join to Master; that's simple enough and best-case-scenario. Now imagine that each Device/Plugin is a new Node/Point/Joint on the way to Master. These can still be parallel for the time being, they're just notable steps along the way. Every single Node/Point/Joint represents a location that can only be processed once the prior Nodes have completed (obviously, your Reverb can only do its work once your Polysynth has completed its). And they're all still parallel except for the final Master merging.

But, any time that you introduce a Joint between these, you have severely limited the ability to be parallel. So when you have a Send that two Tracks output into, that's a very interesting graph compared to before. The end of both Track's go into Master, but they also Join into a new Track/Branch that goes into Master as well. As from before, this Node can only be Processed once the prior Nodes have. Having another Core/Processor here is useless since it's waiting for everything before it to finish, and once those are finished the original Core/Processor that was working on them is now available to use!

Many things are Joints: Audio Sidechains Modulators, Audio Receivers, adding a Track/Device into the 2nd Input of a VST, and so on; these all introduce a path from a separate Branch into another. Every time that happens, the benefits of being parallel are slowly lost. Nodes/Joints have to wait on prior Nodes, and the potential for any *one* thing to be a bottleneck is greater.

In this type of scenario, being very parallel only makes sense if there's very little overhead, and if the work itself is very intense. It's almost the opposite for audio processing: the computations are optimized for small repeated batches of work. There's overhead involved for all of the context-switching that would have to happen to work on different branches of work. In some cases, being more parallel (if possible) would be *slower* than allowing fewer Cores to be "in the zone."

So, like the majority of even above-average computer users, more cores/threads is definitely a lower priority than the clock speed of any individual core.

[stamp]

So, like the majority of even above-average computer users, more cores/threads is definitely a lower priority than the clock speed of any individual core.

Of course it's more complicated then 1 track per core. But don't forget that higher clock speed doesn't mean more processing power in all cases.
Amd cores are slower but can process more instructions per clock then Intel cores. And since a 4 core won't give you faster cores than an 6/8/12/16 nowadays, it's still better to get the most cores you can.
More cores equals more processing power equals more tracks with more plugins.

[Echoes in the Attic]

It's a whole lot more complicated than this....

Very interesting, thanks for that explanation.

So I guess if you were in a scenario where you were not using sidechains, just simple devices per track, but with heavy use of sends, then the processing power needed for those sends would actually add on to the cpu requirements of every track sending to them? So to simplify the scenario even more, if there are 2 instruments tracks, both sending to 4 send effect tracks on a 4 core machine (or more), the effects would actually use cpu from both cores because they were dependent on the 2 instrument tracks that had been split up in parallel over the 2 cores?

I've never actually tested this but is that about right?

[sth]

So, like the majority of even above-average computer users, more cores/threads is definitely a lower priority than the clock speed of any individual core.

Of course it's more complicated then 1 track per core. But don't forget that higher clock speed doesn't mean more processing power in all cases.
Amd cores are slower but can process more instructions per clock then Intel cores. And since a 4 core won't give you faster cores than an 6/8/12/16 nowadays, it's still better to get the most cores you can.
More cores equals more processing power equals more tracks with more plugins.

That's my bad for saying clock speed and not keeping it general with core speed, but it doesn't affect my point at all. If X self-describes as 4.0, Y self-describes as 3.5, yet Y does all the same work in a shorter timeframe, I don't think any reasonable person would call X faster simply because of marketing specs. So, I'm talking about real results and not "technical specifications." It's also not generally true that single-core speeds are the same and your only option is core count.

This is not a simple multiplication problem. The speed of any one core is a very important multiplier, since it's literally always present and affecting results. The quantity of cores is a much less important multiplier, because it does not apply to many use cases (like this one).

It's _not_ better to get the most cores you can. Given the choice - and assuming there's at least a few cores, i.e. not a single-core processor - you will definitely see better results if the overall speed of a single core is better. Taking a small single-core performance hit in order to get more cores will _nearly never_ give a typical user a real gain.

There's very few tasks that can really saturate and benefit from being extremely parallel. Those tasks are also usually long in duration, and infrequent in occurrence. It's the difference between speeding up literally everything, especially the most frequent and noticeable tasks, or speeding up the one huge task.

Very simply: have you maxed-out every core on your machine? No? More cores will not help. Did you max them for 5-minutes today? OK, more cores will help you the next time you do that 5-minute task.

But, faster single-core performance will _always_ help.

[antic604]

@sth, those are very good points!

My blood curls when I read people comparing performance of say Reaper vs. Bitwig/Live/Reason boasting about how the former is superior and - by contrast - how the latter were apparently coded by clueless monkeys. Yet they mostly don't understand or even realize how different the design principles behind DAWs are.

Those creative DAWs do a lot that hurts CPU performance:
- clip launcher means that in any moment the order of what's played - or how it's played, if "dummy clips" are used - can change in response to user's input or even in a random manner (next clip actions), so playback cannot be buffered way ahead of time like most linear DAWs do
- device chains in those DAWs can be much more complex, incl. splitters for frequency, mid/side, left/right, parallel & serial processing, up to audio rate and often random modulation, complex sidechaining for many parameters not just volume, generative sequencers & CV/gate triggers, nesting & feedback, etc. - all of this makes the audio paths branch like crazy
- you can mostly change stuff up - swap instruments, effects, patches, clips, etc. - on the fly, without impacting playback; try doing it in Cubase and it'll get confused very quickly, because it had it already buffered up for 1s in advance and you dare to change it up??

On one hand, such features that Bitwig, Live or Reason have implemented are great because they offer incredible freedom & creative possibilities, very often impossible to replicate elsewhere. On the other, it's easy to make things way too complex and choke the CPU with few tracks, because of convoluted, labirynthine device chains. In other DAWs you'll either give up much sooner and end up with a simpler patch or spread it out across several tracks (making it less interconnected) and thus make it more predictable and therefore easier to chew through for the CPU.

The 'problem' with DAWs like Live, Bitwig or Reason is they're designed & built to handle such setups, but can't disable them for simpler workflows when all this immediacy is not required. So when people that've been using Cubase or Reaper come to Bitwig with their linear workflow - they'll record MIDI or audio, put an EQ, compressor and maybe some delay & repeat that 100 times - they're surprised they can only run half of the plugins/channels they could in their other DAW.

Well, doh! You're "using it wrong" so to say I don't go to Cubase attempting to create complex device chains and generative music. Don't come to Bitwig to track rock bands and orchestral scores. I mean you can do both in either DAWs, but you'll be working hard against the issues that could've been avoided altogether by choosing the right tool from the start.

I don't know why I'm saying this in a thread about CPU, but it somehow felt appropriate

[stamp]

Very simply: have you maxed-out every core on your machine? No? More cores will not help. Did you max them for 5-minutes today? OK, more cores will help you the next time you do that 5-minute task.

But, faster single-core performance will _always_ help.

I was maxing out my old 4 core (I7 4770).
It really depend on your workflow, the plugins you are using and how efficient your audio interface driver is. My work is 100% synthesis based and involves a lot of layering and a project has on average 30ish tracks with up to 6 sends.
With my old 4 core I had to freeze tracks to finish the track (not in always) and I had to think about which plugins to use and where, etc.
Now I don't have to freeze and I mostly use whatever plugin I want. And believe me it's very liberating.
Ah... and don't forget the fact that I payed only 175euro for an 8 core cpu. So getting an 8 core seems like a no brainer, imho.

@echoes I will start testing later today

[stamp]

Just to add to the above. Sth is right: you don't 'need' more cores. But hey...you 'want' more cores. Me at least

[antic604]

Just to add to the above. Sth is right: you don't 'need' more cores. But hey...you 'want' more cores. Me at least

Well, you might not WANT more cores, but you're FORCED to need more due to thermal constraints (there's no consumer CPUs with clocks higher than 6GHz I think?) and chip density, which translates into the cost. We've been closing in to the limit of single-core performance for several years now and unless we go to quantum computing or there's some scientific breakthrough in how chips are printed, we're stuck with going "wide" (multi-core) hence the research on parallel processing has been pushed hard.

I'm also looking forward to GPU acceleration for music. I'm aware that audio is by definition a linear process and GPUs were designed for the exact opposite workflow, but maybe someone clever can come up with a way to split audio processing into small, parallel chunks? For example by splitting - losslesly - the signal into hundreds of frequency bands and processing them separately? Or something like additive synthesis, where sound is generated by combining hundreds of sine waves of different frequency, phase and amplitude?

(BTW, I'd love Bitwig to add native additive synth - I love the sound of Loom, Razor or Harmor)

An i9-9900k has 0.2-0.3 TFLOPS of computational power. The incoming PS5 and Xbox consoles will have 9-12 TFLOPS in their GPUs, not to mention high-end desktop GPUs from nVidia that are in the range of 15TFLOPS. Even if we could tap into 10% of that extra power, we'd have 10x more than we have today

[stamp]

We've been closing in to the limit of single-core performance for several years now and unless we go to quantum computing or there's some scientific breakthrough in how chips are printed, we're stuck with going "wide" (multi-core) hence the research on parallel processing has been pushed hard.

No, we don't. Just because Intel is stuck in it's 14nm loop since 6 years now doesn't mean we have reached the limit of single core performance. Look at Amd with it's 7nm process and nearly 20% more ipc (instructions per clock) vs Intel. And this just Zen2. Zen3 is supposed to increase ipc anywhere between 10 and 15% and floating point operations up to 50%. Ryzen 5000 series is supposed to be based on 5nm process with nearly double the transistor density
of 7nm. Now that we finally have competition in the consumer cpu segment we will see some huge increase in performance over the next years.

[antic604]

No, we don't. Just because Intel is stuck in it's 14nm loop since 6 years now doesn't mean we have reached the limit of single core performance. Look at Amd with it's 7nm process and nearly 20% more ipc (instructions per clock) vs Intel. And this just Zen2. Zen3 is supposed to increase ipc anywhere between 10 and 15% and floating point operations up to 50%. Ryzen 5000 series is supposed to be based on 5nm process with nearly double the transistor density
of 7nm. Now that we finally have competition in the consumer cpu segment we will see some huge increase in performance over the next years.

Sure, but 10-20% every 3-5 years means it's slowing historically. We're only able to still follow the Moore's law because of increasing core count, which is also where AMD is big at: