Maximize Core Performance in Logic?

Hi there,

 

I just purchased a new Mac Pro, and use Logic Pro X as my DAW. I'm running into an issue that tech support wasn't sure about, and shouldn't be happening on a machine of this caliber.

 

In Logic, it's only using some of the cores, and one in particular is spiking sometimes and causing issues. I played around with the multi threading options a bit but it didn't seem to make a difference. Most of the cores are not activating at all, and all but one that are are hitting maybe 40% max on a couple of them.

 

Does anyone know how to spread the workload more evenly throughout the available cores, and keep this spike in one from happening?

 

Note: I'm running a 12 core processor with 96 GB of RAM

 

Any advice is appreciated, thank you!

Is it a 3rd party software instrument?

There's an apple technote about how to spread the load across cores if you search for it. The bottom line is that for performance reasons, in general one channel is processed on one core, so all the plugins on one channel must be able to fit into one core.

 

Not only that, but in Live mode (eg, when you have a virtual instrument track selected and ready for playing), *all* plugins on that channel and in the path of that channel (busses, output channels) etc are forced onto the same core.

 

Also - don't expect cores to *look* evenly distributed (even if it makes you feel better ) - they are not optimised for how the casual person looks at the meters, but for performance. If you are processing too much on one core, then use the tips in the tech note I referenced to spread the load out evenly (basically, spreading the plugin load on heavy channels across multiple channels).

Okay I’ll try to find it, thanks. If you happen to have the link handy that would be amazing! I’m not so concerned about how it looks, just the observation during issues. I definitely need to lighten the load on that particular spiking level though. I am using third party virtual instruments, but shouldn’t be causing issues in a project so small without all the layers added in.

The meter in LogicPro doesn't show core usage it shows thread usage. There is a difference. If you want to see core usage you look at activity monitor application to watch the actual cores.

 

At any given moment in time, your computer will have many threads running and they are sharing time with the 12 cores on your system, taking turns. OSX is in general spreading those threads around to all 12 cores as best it can.

 

In general, LogicPro assigns each track to a thread, but sometimes it can assign more then one track to a thread. It generally will not assign one track to more then one thread. But if you have 100 tracks playing, you don't have 100 threads for example. On your 12 core, you might have up to 24 threads total used by LogicPro and LogicPro is putting track activity for each track to one of those threads. The threads then take turns using the cores, as mentioned above.

 

So if you have less then 12 tracks playing, or maybe even a few more, you will not see all threads being used in LogicPro cpu meter.

 

Sometimes two tracks go to one thread, as I mentioned, so its not necessarily true that exactly 12 tracks would use exactly 12 threads.

 

And anyway, if you watch the activity monitor with say 6 tracks playing, you will probably see all 12 cores getting some use, while the LogicPro meter will be showing only 5 or 6 threads being used.

 

On top of all of that, whichever track you have selected, is in live mode and is forced to the last thread by itself. I'm not sure if Logic locks up one of the cores just for that thread or not (excluding other apps from using that core). But Logic is attempting to make sure that track gets its own dedicated thread, isn't sharing it with any other tracks, so you can get optimized latency on that live track,.

 

This question comes up so often. I wish Apple would post some updated document about the behavior to point people to every time it does.

In addition: "among all of the threads, there is one that is special – the real-time thread." The one that is literally responsible for what is coming out of your computer's speakers, when you aren't doing an off-line "bounce." This thread is so fundamental that it claims "affinity" to one of the CPU cores: no one else can use it. (And, if it can't get its "real-time" job done "in real time," you get the dreaded "System Overload.")

 

Logic divides the remainder of its [real-time ...] activities into asynchronous "threads" and thereby seeks to balance them among available hardware resources, but it is actually the OS/X operating system which ultimately decides how and where those threads will be dispatched upon the hardware that you have. Obviously you would be wise to ensure that no other applications are running while Logic is doing its very CPU-intensive magic.

 

You can exercise considerable indirect control over Logic's real-time CPU utilization by the exact arrangement of your project, but fortunately "real-time" is not the only option available to you. Logic was very obviously designed from the very beginning to have very good capabilities for various kinds of off-line "bouncing and freezing." Here the computer calculates the resulting audio waveform without being obligated to do so "in real time." Although it is somewhat inconvenient to have to go through these "extra" steps, the audio outcome is actually (AFAIK ...) the same. (Much better than a 24-track tape recorder, eh?)

Thank you for these detailed explanations! I guess I was wording my question wrong initially, so yes one of the threads is peaking! Okay I’ll try a closer observation with this information, hopefully I can get it to stop maxing out. All the other threads just have sooo much more room, but I didn’t know any of these details! Very interesting and not so straightforward haha.

Just to add to the confusion:

 

https://support.apple.com/en-us/HT205975

"About the Multithreading setting in Logic Pro X"

Selecting "Playback and live tracks" for the multithreading option does seem to add more latency when playing virtual instruments thru Logic

 

Keep in mind that an application cannot pick which core a thread gets assigned to; that happens transparently at the OS level beneath the app. Now it may be that Logic gives a high runtime priority to the thread for live tracks. However, I believe Mac OS will penalize an application that is too greedy for resources, e.g., always trying to run everything at high priority. The available cores have to be shared with whatever else is running on the machine, so I would quit as many other programs as you can while running Logic under a heavy load. The layout of the signal flow in the mixer I think also effects how well the (DSP) work can be parallelized.

 

I'm not sure how accurate Logic's performance meter is. The activity monitor utility CPU usage windows might give you a better idea of the total load on your machine. Once you open it, from the top pull down menu select Window -> CPU usage - or - CPU history and expand the window to see all physical and virtual (if you have them) cores.

Logic’s performance meter is merely showing thread activity and I agree it is somewhat overrated and misunderstood meter.

It's reasonable to assume that Logic's designers have parsed-out the work of their software into largely independent units-of-work so as to maximize utilization of all available cores, no matter how many there might be. (And they might have been smarter-yet.) But there's still going to be one thread that has to bear the load and thus risk becoming overloaded: that "real-time thread" which I spoke of. The one that actually causes sound to come out of the speaker. It can't delegate its responsibilities to others. It can't be subject to the whims of the operating system, "because you would hear it."

Its not always true that you can or should split out the work into multiple threads. I have a degree in Computer Science and decades of experience in that field. Multi-threaded programming has a place where it works well; and many places where it doesn't work well.

 

The overhead associated with multiple threads sharing data; and sharing time on cores...is not insignificant. Certain tasks are absolutely worth it. That's how and why multi-threaded programming even exists to begin with and why multi-core machines are even useful at all. But nonetheless there are still many times when it is not only unwarranted but even ill-advised.

 

So what I'm trying to say is, its not a simple matter of a program like LogicPro being able to just divide up all the work load on 12 cores and make the machine scream. The thought process that goes into exactly when and how to split off separate threads of execution can be extensive and complicated. I am quite sure that Apple and other developers are doing that as much as they can, in ways that we can't understand and wouldn't want to understand all the details of how and when LogicPro, for example, would choose to fork separate threads of execution.

 

We know this simple fact, more or less. That one mixer channel will not be split across multiple threads. Everything happening on one mixer channel(all the plugins on it, etc), are happening on one thread (for any given mixer channel). (knock on wood), that is probably over-simplified explanation, in reality they could very well be spawning other threads at times to handle certain tasks, but in the case of mixer channel, for the most part the audio has to be processed serially, so there is little gain by splitting the work onto multiple threads, and meanwhile there is the overhead associated with it.

 

Meanwhile we also know that a single thread of execution may be handling the work of more than one mixer channel!

 

If you have 100 mixer channels in your project, it does not fork 100 threads of execution, that would be a foolish policy. Rather the work is queued up into however many threads the application is spawning, which in practical reality is probably something closer to 2 times the number of cores on the system, or less. There are development tools available you can use to see exactly how many threads are getting spawned by every process on your system. You can easily see that LogicPro will never create 100 threads.

 

So that means, while its true to say that one channel will never be on multiple threads, its also true that multiple channels could be sharing a single thread.

 

How and when LogicPro decides to stick one mixer channel onto an existing thread, vs when to spawn a new thread...would be internal information we don't know, and I'm quite certain is more complicated then the often-recited idea that there is one thread per channel. There is simply not a 1:1 correspondence of thread to channel...the threads are sharing multiple channels. But everything within a single channel is most likely happening all within a single thread, usually time shared potentially with other channels too. A specific plugin may of course opt to fork its own threads for whatever reason, but LogicPro is not keeping track of that or know anything about it.

 

The one exception to the above is that LogicPro says that if you have a LIVE channel...then in live mode, that particular channel will have one thread devoted entirely to itself and won't be sharing time with any other mixer channels.

 

As to how these threads use time on the cores, as said earlier, that is a factor of the operating system. Applications are all starting at a minimum one thread.. So when you look at activity monitor you might see 30 processes running. At a minimum they each count as one thread each. Many apps will have multiple threads happening separately, so at a moment, between all your apps you might very well have 100 threads across all apps and processes on your system. Those threads are all sharing time across or 6 or 12 or however many cores you have...and the Operating system is determining how and when to queue those tasks up on the cores.

 

Regarding the Live channel, it is also subject to the operating system! LogicPro does not have that core isolated. The reason you don't hear glitches is because of the audio buffer. Having that one mixer channel isolated to one thread just means that one thread isn't sharing time with multiple channels, so the live channel will be able to complete all the work it needs to do within the timeframe of the audio buffer. Therefore you can reduce the size of the audio buffer and not get drop outs. If that channel had to share time on a thread with other channels, then you would not be able to lower the audio buffer quite as much.