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.
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
startcommand. 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
powercfgto ‘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’:
NoThrottle.vst3 in the
C:\Program Files\Common Files\VST3\ folder. Before deploying you should scan it a reasonable malware scanner
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:
The plugin only has one parameter, called
GUI Throttling. It has four possible selections:
On: Power throttling is switched to on for the Gui thread.
Off: Power throttling is switched to off for the Gui thread.
Default: Power throttling is left to the default policy of Windows.
Skip: The plugin does not interfere with the throttling settings.
- When the
GUI Throttlingis switched from one of the other choices to
Skip, Power throttling is reset to
Defaultfirst, but after that the setting will no longer applied again (until the setting is switched to one of the other choices).
GUI Throttlingis set to
Defaultthe setting is re-applied every second.
- When the plugin is newly inserted,
GUI Throttlingis set to
Skipwithout applying any Power throttling policy.
- No policy is applied when a saved project is loaded and the saved setting was
- 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.
You can find the source code here: GitHub - frank1119/NoThrottle
- 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