Possible helper plugin for modern Intel CPUs

[Frank1119]

I recently bought an Intel NUC13I7xxx. This system uses an I7-1360P (13th gen) processor which has 4 performance (P) cores with a hyper-thread each and 8 efficiency (E) cores. The P cores are much faster than the E cores. Normally, Windows will schedule processes among the P and E cores, depending on load and necessity.

Main thing is that it is undesirable to have the audio thread of Gig Performer running on an E core, because this seriously limits the maximum number of possible plugins, depending on de load of these plugins.
As long as the (main) window is visible to the user (in other words: not made invisible by another window and also not minimized), Windows default policy is to schedule a process on the P cores as much as possible.
However, when the windows of an application are no longer visible, Windows assumes that the performance of the process doesn’t matter any more to the user and will allocate E cores for that process. As stated before, this is undesirable for Gig Performer, but may occur when running an instance more or less headless.

Possible solutions:

• Disable E cores in the systems BIOS. This seems rather simple, but the main drawback is that it forces all other processes, including ones you do not care for too much, to run on the remaining P cores, forcing them to compete with Gig Performer

• Set the affinity of a Gig Performer process to the P cores. This can be accomplished using the start command. The drawback is that the whole process is unable to take advantage of all cores, even for threads that could easily run on E cores

• Use powercfg to ‘hint’ Windows that you don’t want power throttling for all process instances of a particular binary: syntax: powercfg /powerthrottling disable /path "C:\Program Files\Gig Performer 4\GigPerformer4.exe". This is really not a bad solution, although it lacks some granularity (the same way setting the affinity mask does), but it leaves at least some decisions to the OS (although I don’t know if Windows will take advantage of this)

• The process itself can have threads opting-in or out for power throttling. This is in my opinion the best solution, but not immediately available. Gig Performer would have to be modified. That would mean a new release and a lot of testing, especially because it touches the very core of Gig Performer: The audio thread.

• A solution somewhere in between: A (vst) plugin runs (at least) partly on the audio thread and partly on the GUI thread: Inserting the necessary code can solve the issue in a rather granular fashion: Disable power throttling for the audio thread and enable it for the GUI thread (or just leave the GUI thread alone).

For this last solution, I’ve created a vst plugin. This is the ‘manual’:

Installing

Drop NoThrottle.vst3 in the C:\Program Files\Common Files\VST3\ folder. Before deploying you should scan it a reasonable malware scanner

Checksums NoThrottle.vst3:
SHA256: 94ff54fd0e9295a48647daac023a32726e5769cd0de067ef0ffda129e86a4e75
SHA1: 89e2a887a9dba5721141c1922e862cfe3da4f687

Usage

Just insert the plugin and adjust the GUI Throttling parameter (see below). It does not need to process any audio data. When the plugin window is opened, the status line will indicate whether it is active or not by a ‘turning’ dash:

Parameters

The plugin only has one parameter, called GUI Throttling. It has four possible selections:

1. On: Power throttling is switched to on for the Gui thread.
2. Off: Power throttling is switched to off for the Gui thread.
3. Default: Power throttling is left to the default policy of Windows.
4. Skip: The plugin does not interfere with the throttling settings.

N.B.:

• When the GUI Throttling is switched from one of the other choices to Skip, Power throttling is reset to Default first, but after that the setting will no longer applied again (until the setting is switched to one of the other choices).
• When GUI Throttling is set to On, Off or Default the setting is re-applied every second.
• When the plugin is newly inserted, GUI Throttling is set to Skip without applying any Power throttling policy.
• No policy is applied when a saved project is loaded and the saved setting was Skip.
• Power throttling is always switched off for the audio thread. This is re-applied every second.
• Bear in mind that the settings are applied to the threads of a running process and persisted as long as that process runs. So to reset all effects of the plugin (especially to the audio thread), the process must be ended and restarted.

Github

You can find the source code here: GitHub - frank1119/NoThrottle

Disclamer

• This software is not officially endorsed by Gig Performer or Deskew whatsoever
• When using this, you are de-facto a beta tester, so please, do not use it immediately for an (important) performance. First, try it out in a rather unimportant setting.
• Let me know if there are problems, for example, it does not work anyway or worse, it crashes Gig Performer or your system.

NoThrottle.zip (2.0 MB)

I hope someone finds this useful. I had fun creating it anyway

[dhj]

Awesome concept - thanks for creating this.

@Frank1119

Before deploying you should scan it a reasonable malware scanner

Have you considered providing a checksum for the compiled plugin that people can use to verify that they have your original version?

[Frank1119]

@dhj

Have you considered providing a checksum for the compiled plugin that people can use to verify that they have your original version?

Yep, that is something I really should do, especially since I urge people to be careful.

NoThrottle.vst3:
SHA256: 94ff54fd0e9295a48647daac023a32726e5769cd0de067ef0ffda129e86a4e75
SHA1: 89e2a887a9dba5721141c1922e862cfe3da4f687

[edm11]

Very good thread here.
I very recently purchased a NUC12WSHi7, and while I have had some luck adjusting performance with Quick CPU, I am eager to try your plugin.

[npudar]

Awesome idea!

What would be interesting: to measure the impact of this approach – A/B.

@Frank1119
Can you do that on your computer.

[Frank1119]

@edm11

and while I have had some luck adjusting performance with Quick CPU, I am eager to try your plugin

It really no replacement for Quick CPU, ThrottleStop and the likes. I complements it. But your welcome to see if it works for you (of course).

[Frank1119]

@npudar

What would be interesting: to measure the impact of this approach – A/B

I did some testing:

The setup (without NoThrottle):

The two additional Guitar Rig instances are just there to create artificial load. You can see the CPU is rather high: 41%

The result in the Task Manager is this (while Gig Performer is hidden):

You can clearly see that there’s a lot of load on the 16th CPU (bottom right). The CPUs with the highest numbers ar E cores (in my case CPU 8 - CPU 15)

The setup (With NoThrottle)

In the above example I’ve left the handling of the GUI Thread to Windows.

The result in the Task Manager is this (while Gig Performer is hidden):

Now CPU 0 takes the load (and some on CPU 4). More important is that the 8 E cores at the bottom, are doing close to nothing.

So, it is really forcing Windows to use the P cores for the audio thread. Most important: Does it matter for audio glitches? Yes, it does. When GP runs on an E core (fully saturated) then the audio drops and have glitches like whatever. Bit crushing to the max . But when GP stays on the P cores, I still have some CPU headroom and no audio glitching.

[DaveBoulden]

This looks excellent. Just a quick question, should it be placed in every rackspace, or can it be added just the once to the Global rackspace?

[Frank1119]

It’s ‘process-wide’ so just 1 in the global rackspace should be enough.

Something for version 1.1.0: check for multiple instances and issue some info/warning

[jeffn1]

Dumb question: I am am using a laptop (which is always open while I am using GP), so I probably do not have to be too concerned (?)

On the other hand, this is probably very important for people who use NUC’s(?).

[Josehdx]

Another dumb question. Looks like this vst is v3

This version is known to “save” performance when no audio is detected. Is not better to use v2 version instead?(always active) thanks

[Frank1119]

In GP it stays active, unless you hit the bypass button of GP. As long as you see the ‘throbber’ turning audio is being ‘processed’. Not there is much to process, hence the quotation marks. So you don’t have to connect it to an input. I just added it for use in other plugin hosts that might be doing intelligent stuff that no one expects it to do (most of the time).

[Frank1119]

@jeffn1

I am am using a laptop (which is always open while I am using GP), so I probably do not have to be too concerned (?)

As long as GP is visible Windows thinks you’re interested, so it will probably use P cores. But when another window is overlapping (for example a maximized task manager) Windows might start allocating E cores.

@jeffn1

On the other hand, this is probably very important for people who use NUC’s(?).

It might be important for everyone using a cpu that features P and E cores. Whether it’s a laptop, NUC or desktop doesn’t matter in this regard.

I use two GP instances at this time, but that number might increase. And then I eventually will run out of display room. Then maybe some instances will be no longer visible…

[Frank1119]

@Frank1119

In GP it stays active, unless you hit the bypass button of GP. As long as you see the ‘throbber’ turning audio is being ‘processed’

Just to clarify: Under normal circumstances, The settings will persist for the duration of the process. I only refresh the settings about every second, just in case some other component (could be even another plugin, although that’s not likely) tries for whatever reason to reset or alter these settings. So chances are in most circumstances that only activating for a few seconds could be enough.

For the next version: Add a ‘one-shot ↔ refresh every X seconds’ button…

Hmm…, I hope this clarifies it, but I’m not sure

[dhj]

Maybe you should have an option to turn that refresh off so people only need to automatically refresh if there actually is another plugin messing it up

[Frank1119]

@dhj

Maybe you should have an option to turn that refresh off so people only need to automatically refresh if there actually is another plugin messing it up

@Frank1119

For the next version: Add a ‘one-shot ↔ refresh every X seconds’ button…

Yep, I was thinking that also