Anyone know how PT selects which CPU cores to saturate ?

[ejinbc]

Yo

I have a new 13900K CPU with many threads sitting idle while 2 of the threads saturate. With the new systems one can overclock specific cores while underclocking other cores (to improve thermals).

So which cores to overclock ? How does PT select the cores to saturate ?

Cheers

ejinbc

[JFreak]

PT doesn't choose. It is the Intel Northbridge chip which has no clue what is happening. Apple Silicon can distribute the load evenly, difference is beyond huge.

[Teej]

Originally Posted by ejinbc

Yo

I have a new 13900K CPU with many threads sitting idle while 2 of the threads saturate. With the new systems one can overclock specific cores while underclocking other cores (to improve thermals).

So which cores to overclock ? How does PT select the cores to saturate ?

Cheers

ejinbc

Also keep in mind:

Lots of tracks with lots of plugins = all cores used.
One or two tracks with loads of plugins = one or two cores used.

One track's load cannot be spread across multiple cores, the math has to be done in order of the signal flow of the track (Insert A to Insert E etc) and cannot be parallelised. EQ1 --> Compression 1 --> Autotune --> Reverb --> Chorus --> Compression 2 ... it can't process Compression 2 before the rest of the chain has been processed.

[Darryl Ramm]

Originally Posted by JFreak

PT doesn't choose. It is the Intel Northbridge chip which has no clue what is happening. Apple Silicon can distribute the load evenly, difference is beyond huge.

Negative Ghost Rider. The placement of threads on cores is managed by software, either the operating system and/or application software, it is not decided by hardware, and definitely not by the Northbridge chip or functions in it. (And the 13900K and other recent Intel CPUS do not have a Northbridge chip, with all the different stuff the Northbridge did do now in the CPU... but none of that is making decisions where to place software threads).

This is complicated here by e-cores, and confused by Intel's marketing talk about Intel Thread Director... which is technology for better helping operating systems make thread placement decisions, not for making those decisions for the OS. Being on Windows 11 with improved Thread Director support might help, might not.

Why the native port of Apple Silicon might shows more even CPU core use is up for speculation, the proof in the pudding is not what some CPU meters says (and again Avid changed CPU metering here), it's how large a session/load you can run on a system without getting CPU errors. And sure Apple Silicon Macs seem fast/good so far, and they are likely (out of necessity) also getting a lot more engineering attention than Windows PC systems.

Originally Posted by ejinbc

I have a new 13900K CPU with many threads sitting idle while 2 of the threads saturate. With the new systems one can overclock specific cores while underclocking other cores (to improve thermals).

What exactly are you looking at? If it's Pro Tools CPU meters you are likely wasting your time.
I would be starting by fully optimizing that Windows PC, I'd get representative sessions/benchmarks fired up and and see how stuff performs. If you can't push the system with reasonable/usable size HW Buffer size to have CPU errors then there is nothing to bother adjusting. If you are riding on the edge of CPU errors then it gets interesting and you have something useful to look at as you adjust stuff.

I have no idea how much thread optimization has really been done by Avid in Pro Tools on Windows. The assignment of plugins etc. threads by signal chain onto the same cores may just be Pro Tools setting thread affinity mask to try to improve cache performance. Pro Tools may already give Windows enough performance hints to avoid being scheduled on an e-core, but who knows, and who knows if deeper optimization like deliberate use of e-cores might even make sense for some tasks. If you are technical and interested I encourage you to play around (and please tell us what you find).

Changing CPU core overclocking might be a nice idea but would not surprise me if it ends up being a waste of time. If you are technical and want to play that way you ideally will have a reproducible benchmark/test load that lets you investigate making changes, and as stuff here is likely to be very workload dependent you hope that benchmark workload represents your real work experience. As Teej points out this is all dependent on what you are doing, the workload, plugin signal chains, the actual plugins etc. can all make a lot of difference. And if you are seeing cores really slammed by threads and want to make a significant difference that is likely to come from changing that not tweaking the CPU settings. And how much can you overclock and not cause problems? How does overclocking a core interact with Thread Director trying to use core thermals to hint the Windows scheduler? Has Pro Tools pinned those threads well enough they won't move even with new scheduler changes? (I expect so) All a potentially complex system to explore and if wanting to go there I'd be poking around to understanding stuff, using a good benchmark(s) and spend time playing.

Again be very careful what any CPU usage meter are showing especially the Pro Tools usage meters, which have changed how they calculate what is being displayed several times and a quick look at systems instrumentation will often show completely different performance data. Avid has really needed to document for a long time just what these meters are showing (and that was a frustrated comment to me by an Avid developer nearly a decade ago... and it's still not happened).

[ejinbc]

DR

Thanks for your thoughtful response.

I agree with your understanding. I am using the Windows Resource Monitor to look at core activity. I am used to thinking about affinity settings for core optimization at low latency with my old Win10, 8700K, MOTU 1248 system - it definitely helped.

I am now on Win11. It looks to me that Windows (or something) is very good at loading one thread per core now (as if hyperthreading was off) which helps with efficiency and thermals. But with the session outlined below, I find 3 of the cores are running at around 80% - with no dropouts. I am reasonably technical so I will eventually look at per core optimizations.

With respect to my sessions, I typically use 2 instances of Kontakt (Abbey Road Drums, and various Keys), an instance of Omnisphere, and maybe 12 raw audio tracks. This gives around 24 tracks with an instance of CLA MixHub on each. I have 4 effects busses typically running HDelays or HVerbs. The new system is able to run this 24/48 at 64 sample buffer while recording with no dropouts - I may never adjust the buffer size again ! These are live recordings that are monitored through PT, so low latency is important.

Also, with respect to various processors and DAW performance, the most quantitative data I have seen is here:

https://gearspace.com/board/music-co...hmarks-33.html

Cheers and Thanks.

ejinbc

[Bob Olhsson]

I've been told plug-in developers can actually choose.

[JFreak]

"I don't know but I've been told, a frog man's money is good as gold..."

[cqd]

Process lasso might be worth picking up..
You can set affinites and power plans/memory usage for specific programs..
Kind of tightens up performance I find..

[Darryl Ramm]

Originally Posted by ejinbc

DR

Thanks for your thoughtful response.

I agree with your understanding. I am using the Windows Resource Monitor to look at core activity. I am used to thinking about affinity settings for core optimization at low latency with my old Win10, 8700K, MOTU 1248 system - it definitely helped.

I am now on Win11. It looks to me that Windows (or something) is very good at loading one thread per core now (as if hyperthreading was off) which helps with efficiency and thermals. But with the session outlined below, I find 3 of the cores are running at around 80% - with no dropouts. I am reasonably technical so I will eventually look at per core optimizations.

With respect to my sessions, I typically use 2 instances of Kontakt (Abbey Road Drums, and various Keys), an instance of Omnisphere, and maybe 12 raw audio tracks. This gives around 24 tracks with an instance of CLA MixHub on each. I have 4 effects busses typically running HDelays or HVerbs. The new system is able to run this 24/48 at 64 sample buffer while recording with no dropouts - I may never adjust the buffer size again ! These are live recordings that are monitored through PT, so low latency is important.

Also, with respect to various processors and DAW performance, the most quantitative data I have seen is here:

https://gearspace.com/board/music-co...hmarks-33.html

Cheers and Thanks.

ejinbc

Ah modern CPUs. Thank you AMD (and Apple) for waking up complacent, lazy Intel. The high-end Raptor Lake sure look nice. Will be interesting what happens with Meteor Lake vs Raptor Lake. The Israel based design team seems to be kicking ass and not stopping to take names.

So you face the not-unusual optimization problem of if you can't easily measure the important metric it's near impossible to optimize for it. But it can be easy to spend lots of times changing things. That last few percent of whatever is just so extraordinarily hard to achieve. Here I'd just leave stuff unless you find a problem to optimize against.

DAW bench, is a handy tool, seems not widely used amongst Pro Tools users (lack of a preconfigured session is an issue), but to me maybe some of the best parts of DAW bench are just the discussion/community interested in DAW performance. Some of the Pro Tools demo sessions can be handy for creating load, but how much they are relevant to any user's specific workload... who knows. Best thing is if your sessions are similar or at least the ones that have problems are similar then use them or copies of them with different content that you can use more easily.

Disabling hyper threading has helped folks but it depends on a lot, include the plugins used. And the most common processor affinity stuff of keeping Pro Tool off CPU 0 is helpful, maybe not rocket science. Lots of use is made in many different areas for of keeping user processes or even parts of the OS off of the CPU core handling hardware interrupts, either to improve I/O performance or stop it causing problems for the applications as done with Pro Tools. (On old high-end UNIX systems we'd exclusively place disk interrupt handling on one CPU core, and keep everything else off it (besides just being load, other stuff could also smash the cache and slow the interrupt handling) would make a noticeable difference but typical only for some of the larger TPC benchmarks... and when customers tried to replicate those advanced TPC benchmark type tuning settings or similar they might make their systems worse or never be sure if it made any difference--again that workload/testing thing).

[lesbrunn]

Originally Posted by cqd

Process lasso might be worth picking up..
You can set affinites and power plans/memory usage for specific programs..
Kind of tightens up performance I find..

Yes