I see, that’s probably why we’ve never heard of it 
If you can share from those support emails, please do.
Okay, so something changed, it wasn’t an issue before, at least in my own testing and what I’ve heard from everyone in here using Apple Silicon machines.
Sure, see at the bottom of this post. And this is the general issue with a forum of this type - it’s been talked over till death, but then the posts fall down the stack, never to be noticed, nobody searches, and so we can just explain the same things over and over again to each other, it’s not great and we need that wiki. Anyho…
Nope, it’s the other way around - more threads consume more CPU, in and of themselves, because there’s a CPU overhead for running each thread. That’s why you should run as few as possible.
Exactly, you see 4 threads consuming much more CPU than 1 thread. Now, you’re running macOS and the process monitor works differently than it does in Windows (why keep it simple). So, in macOS that figure means “how many percent OF ONE CPU CORE does the process use?”. So 311% means “using a bit more than 3 cores fully”.
Ok, so here goes - Lars’ explanation of Rack performance, and how to make the most of it, with most important things on top, and please do also read what the manual says about it:
-
Only run as many threads as you absolutely need. So in the Engine->Threads menu you start with 1 thread. Only when your audio starts crackling you add 1 more thread, etc. and only after also applying the below performance tips. The reason is that adding more threads is NOT free!. Each additional thread added consumes some CPU because of thread scheduling overhead, sometimes a lot more, so always start with 1. In my own patches, on my own machine (an 2013 Core-i7 iMac), I never go above 1 thread, because by the time I get to adding another one the machine is already unpleasant to use, plus I never make monster patches.
-
Have a decent graphics (GPU) card. Doesn’t have to be fancy just “discrete” meaning “not the inbuilt Intel graphics” (or AMD) in your CPU. The reason is, that if the GPU cannot cope with the load of rendering the graphics, the CPU takes over that duty, and so you end up burning a lot of CPU for just rendering graphics. The card has to be external to your CPU, so like the manual says:
* Graphics: Dedicated Nvidia/AMD graphics card from 2013 or later with recent driver update
* Integrated (non-dedicated) graphics such as Intel HD are not recommended and may cause significantly increased CPU usage.
-
Run with as high a block size as you can in the audio module. If you are using external MIDI sources, e.g. a MIDI keyboard, and you need snappy/responsive/low latency, then gradually lower the blocksize until the latency is acceptable, but no more. The reason is that the lower the blocksize the more CPU is used.
-
In the audio module, run with a sample rate of 44 or 48KHz. Only higher if you have a really good reason to. The reason is that the higher the sample rate the more CPU is used.
-
In the Engine->Sample rate menu, run with the same sample rate as the audio module, always, unless you have a really good reason not to. It should usually be the “Auto” setting in that menu I believe, where auto means “same as audio module”. The reason is that if you don’t run the Rack engine and the audio module at the same sample rate, you will burn a lot of CPU re-sampling everything needlessly.
-
Use CPU efficient modules. This is one of @Squinky’s pet peeves but also mine. There is a lot of variance between modules in CPU consumption, even if the modules otherwise look the same, with the same amount of functionality etc. It’s got everything to do with how well they are coded. There can be 10 x or a lot more variance in CPU consumption between otherwise identical modules. So put it to the test. When you’re deciding “which LFO should I use?”, put the 3-4 candidates next to each other, patch them up so they’re working, also very much with respect to whether you’ll be using them mono or polyphonically, hit F3 so you can see the CPU usage of each one and then decide. Using efficient or inefficient modules in your patch, especially big patches, has an awfully big consequence on the CPU usage of that patch.
-
In the View->Frame rate menu, lower the graphics framerate if the machine is struggling. That can save quite a bit of CPU as well.
-
Minimize the Rack window when you can. If you’re in a place in your workflow, where you’ve hooked up a recorder, and the patch is playing by itself, or you’re jamming on your MIDI keyboard, minimize the window. That will moderately, or sometimes dramatically lower the CPU usage. The reason is (I think) that, depending on graphics drivers, OS, etc. the GPU and CPU doesn’t have to do any drawing of graphics when the window is invisible, and drawing Rack and all the modules and graphics does take a toll on both GPU and CPU, so you’ll be saving cooling/heat/fan-noise plus some/a-lot of CPU.
-
Have the Engine->Performance meters (F3) off when you’re not actively using it, because that uses some CPU as well.
That’s everything I could think of that’s accumulated over the years. There’s probably a couple of things I’ve forgot, but it’s going to be a while before I’ll bother to write that up again (again again), so now it’s up to y’all to point to this post when people are wondering about performance
Thank the stars that things like “SIMD Everywhere” exist.
