While working on some screenshots for an upcoming blog, I noticed something that something was off with the performance of Simics on my Windows 11 laptop. The CPU load did not quite go as high as I am used to – typically, compute-intense run should get close to 100% processor load using a single host thread to execute the simulation. Instead, I got to no more than about 50%, which was decidedly odd. I also had a screenshot from a few days earlier that showed some 90% CPU load. Turns out the culprit was a combination of factors, including the Windows 11 scheduler and the Corsair iCUE software pack.
Cue iCUE
Turns out that I had recently installed the Corsair iCUE software pack on the laptop. I am an avid user of Corsair keyboards, and I very much like the ability to customize key lighting on a per-key RGB basis. It simply looks good. There are also some fun features, like having keys on the keyboard reflect the current processor temperature.
iCUE has grown in recent versions, and really it is insane that the software takes up some 3GB of space when installed! However, like most peripherals today, without the appropriate software, you get much less value out of the keyboards. Logitech, Jabra, Razer, and other manufacturers all have apps that are basically required to make mice, microphones, keyboards, cameras, and headsets function well.
It turns out that having iCUE installed adds some services and drivers to Windows, and that those interact quite badly with Simics (and quite possibly other software as well). Installing iCUE made Simics require about 20% more time to complete the same workload! Somehow, whatever it is doing in the background is enough to noticeably impact Simics. That is bonkers.
However, maybe iCUE was not solely to blame. Redoing everything carefully from scratch, the CPU load measured by Simics did reduce from 95%-ish to 90%-ish after installing iCUE, and reverted back up to 95%-ish after uninstalling and rebooting. That is not quite the same as cutting it down to 50%!
So where did 50% come from?
Note that the CPU load figure is scaled such that 100% represents the full usage of a single host core. Running a multithreaded simulation can easily go beyond 100%, but dropping far below 100% is odd unless the simulator is explicitly pausing waiting for something while it runs.
Windows 11 Scheduler
The reason for the 50% CPU load seems to have been the Windows 11 scheduler. It looks to me like Windows 11 has become much more aggressive about de-prioritizing background work, compared to Windows 10 and maybe even earlier releases of Windows 11. This did not use to a be a problem, and I do not recognize the behavior.
Running Simics from the command-line on Windows, Windows apparently decides that the console windows that Simics opens are the representatives of the real application. The command-line in the terminal is not. Thus, we get the behavior that when the console window is in focus, Simics gets a high host CPU percentage.
When the console window is not in focus, Simics gets much less host CPU.
The original experiment indicates that combining background mode with iCUE often reduces the Simics CPU load to less than 50%. It is not a recommended combination.
Running Simics without console windows makes the application permanently not quite as important to Windows.
It gets even worse if some other program is brought to the front. Such as reading emails or using a web browser while waiting for the run to complete. This noticeably reduces the CPU given to Simics to consistently between 30% and 50% (even with the Simics terminal session and console window visible on the screen, but not in focus). Even if all other applications are minimized and Simics is alone on the desktop, clicking on the desktop and thus dropping the focus on all Simics-related windows causes the “background drop”.
Changing Windows Background/Foreground Priority?
I tried changing some settings to see if that would help. Changing the Windows power plan to “performance” did not affect the CPU load figures, even if the laptop overall might gain some performance by clocking higher. That at least is expected behavior.
There is an advanced Windows setting that is supposed to change the scheduler balance:
This did not solve the problem. It actually made it worse. With the “background services” setting in effect, it did not matter if the Simics console window was in focus or not. Instead, Simics was limited to about 70% CPU load all the time. Maybe some other processes are even more background?
Recording the Effect – Not
I tried to use a screen recording program to make a video showing the effect on host CPU load, but that did not work at all.
Windows considered the video recorder itself as the most important front-end program and thus Simics got about the same 50%-or-less CPU regardless of whether the console window or the command-line shell were in front. Predictable but also interesting. And showing the potential pitfalls of some software with this Windows 11 behavior.
Raising the Priority
What does seem to help is raising the priority of the Simics process using the Windows task manager. When created, the process is at priority “normal”. Raising this to “above normal” has some positive effect. Raising it to “high” definitely gives the Simics process more time.
With high priority, Simics gets up to 100% CPU in the console-window-in-focus case, which is an improvement from all previous observations. When the Simics command-line in Terminal is in focus, Simics gets around 96% CPU. The Windows down-prioritization of processes that are not in focus is still noticeable, but the effect is much less.
Take-Aways
The Windows 11 scheduler is not playing nice with compute-intense programs that are not interactive and at the top of the window stack, or that do not set their own priority to high enough. Windows 11 appears to put much higher emphasis on front-end programs than I have seen prior versions of Windows.
For best performance on Windows, reduce the other noise on the machine. Do not run a web browser, the whole office suite, video editors, and similar if the goal is to maximize the performance of something compute-intensive. At least on a somewhat cramped-for-processor-power laptop. Not sure how this works on a high-powered desktop or similar.
Handy background tools can have a real impact on system performance. Not really news, but the impact was greater than I expected it to be. The openness of the Windows and PC ecosystem has the benefit that hardware can add their own drivers and optimization layers to the software stack. That is what makes PCs the best multipurpose computing tool ever invented. But badly written or overly aggressive features can also impact the rest of the system adversely, especially for lower-power products like laptops. The cost is likely much less noticeable on a high-speed many-core gaming rig.