Bitwig not using M4 e-cores (6 out of 10) confirmed by Bitwig Support

[cafebabe]

So I just got confirmation from Bitwig tech support that the reason the DAW isn’t utilising the 6 efficiency cores of my 10-core M4 is because of certain features like the Clip Launcher. Apparently, these features make it tricky for the software to schedule work across the lower‑power cores.
I’ve got to be honest, I’m a bit disappointed.

I bought a 10-core M4 expecting Bitwig to take advantage of all that headroom, but right now it feels like I’m leaving a lot of performance on the table. I get that the Clip Launcher is central to how Bitwig works for live performance, but I personally never use it – I’m strictly in the linear arrangement workflow.


Is it a good idea to propose a mode in Bitwig where the Clip Launcher and other non-linear features that block efficiency-core usage are disabled, allowing users to benefit from full core utilisation while others can maintain the current behaviour?


I assume a lot of users aren’t touching the Clip Launcher in their day‑to‑day production. If that’s the case, it seems like a fair compromise – better multicore performance for those who want it, without taking anything away from live performers.


Curious if anyone else feels the same or if I’m just in the minority here. Would you use a “linear‑only” Bitwig mode for better performance on Apple Silicon?
I’m even considering cancelling my rent to own plan on Splice and switching to Pro Tools or Cubase since they can use my hardware fully, even though I’m sad to lose everything that makes Bitwig great.

[stoopicus]

Well you definitely wouldn’t want to use the efficiency cores for any of the audio threads.

[gulugulufish]

Bitwig certainly isn't alone here. Apple themselves fail to fully utilize them in logic. I feel your pain though, you want to use the cores. Maybe worth demoing/benchmarking cubase and seeing just how much more you're able to run practically speaking. Maybe net result isn't as dramatic because efficiency cores won't be able to add that much dsp power overall, only guessing

[lfm]

Not sure why Intel go down this path with useless E-cores, why would you want two-speed threads in a process?
- I think it is good that devs Bitwig exclude E-cores, will make things more predictable in process
- luckily I have 8 P-cores(with HT 16) and 4 E-cores, and just turned off E-cores
- benchmarks at cpubenchmark.net just went from 31000 to 29000

I have i7-12700F cpu and it runs constantly at 4.5 GHz and no hops up/down as you watch cpu in Taskmanager.

But also had audio dropout problems for months, until I got a 3rd party USB 3 PCI Express card, so the single Intel usb controller to run all usb is something wrong with IMO.
- my card is based on NEC chip and Renesas drivers
- very cheap to check if this helps, $25 or so

Before my current daw computer I had internal audio cards with no issues, but this one first with usb audio, so ran into these problems.

[BertKoor]

Not sure why you're going down Intel, since "M4" is a type of Apple `Silicon` cpu.

[lfm]

I did not dip my "toe" deep enough.
- there are Intel Mac's too

So it's an industry trend with two tier cores, even worse.

Thanks for heads up.

[uOpt]

Efficiency cores are fast enough for audio. Otherwise we wouldn't get hundreds of tracks on dawbench.

Does bitwig use E-cores on Intel/Winblows?

In any case it makes zero sense to turn off e-cores but allow hyperthreading.

[stoopicus]

e-cores are half the speed of primary cores and also have a scheduling latency hit (though minor in terms of audio latencies).

You would want to prioritize them for UI and I/O threads and not audio.

[uOpt]

e-cores are half the speed of primary cores and also have a scheduling latency hit (though minor in terms of audio latencies).

You would want to prioritize them for UI and I/O threads and not audio.

You can be sure that all software by default runs UI on performance cores. Wanna look snappy.