Anyone else find this 2.2.1 release more CPU hungry? A patch I was playing perfectly OK yesterday (albeit at a fairly consistent 91-95% CPU utilisation), is now showing OVERs at regular intervals. Updated to this new firmware this morning. Nothing else has changed.
Strangely, after leaving it a couple of days and rebooting a couple of times, the CPU utilisation has gone back to where it was, so the patch is now playable again?! Any ideas what else could cause a patch to intermittently utilise more CPU with no apparent changes?
The amount of CPU a module uses depends (among other things) on how much modulation it’s receiving — and fast modulation requires more calculations than slow modulation. So a little spike to the rate of an LFO, or a coincidence where two or more variable-rate modulation sources happened to be going fast at the same time, could easily nudge a patch from 95% to 99%.
There’s also the dynamic load balancing that happens in patches with 3 or more modules. When you load and play a patch (or add or remove a module) it runs each module for a bit and gets an average load. Then it divides them up in to two groups, trying to make the loads as equal as possible. Sometimes if one or more modules has an irregular load then the grouping of modules might be less than ideal and you see a few % increase.
The irregular load could be from time/block based processing (e.g. spikes) or it could be from the params (e.g. as frequency goes up, the load goes up).
Also the processor has two levels of cache memory and depending on complex behaviors, certain code paths or data might be “cold” when the load test is run, skewing the results a tiny bit.
So, lots of factors can add up to a few percent differences.
That’s interesting, as over the last few days, I’ve seen CPU spiking most when loading the patch for the first time that day. However, one of the things I’ve been trying, to address high CPU, is rebooting, and I’m presuming that code paths and data “warmth” couldn’t be sustained through a reboot as this would clear any cache. I have just loaded the patch in question for the first time since Sunday, saw CPU at 95%, then rebooted, run the same patch, and the CPU utilisation is 82%. All the modulation parameters are the same on both occasions in this initial state.
I’m playing this patch live on Friday, though fortunately I’m the second act to perform and we have space for 2 people to set up, so I have time to reboot a few times and hopefully see the CPU utilisation come down before I’m due to play!
That’s a big spread 85-92% but a single module being pushed to one core or the other could do that.
If you do File Menu > Reload that will recalculate the load balance in the patch, without needing to reboot.
Thanks for that - as it was when I got to the gig I got lucky and the patch came up at 84% CPU first time.
When this situation occurs, with the load balancer being inconsistent with the way I’m using modules, is there any way to “freeze” its allocation once I get a low CPU usage so that it doesn’t vary each time I reload? ( I suspect not, but it would be a really helpful feature, as would the ability to “see into” the load balancer to try and identify which modules are varying so much in CPU usage and “fooling” it).