I have a 10-core, 20-thread Intel Core i9-7900X 3.3GHz CPU. I've been running between 18 and 20 threads on it for around four years, mostly under Windows 7. A few months ago I switched to Windows 10. I just noticed something odd with the way my programs run.
They are all console mode programs, and they do little to no screen I/O most of the time.
Until now, they have all run at 'maximum speed', ie every thread has had a full share of cycles. This is observable in the stats the programs keep, the simplest being a rate of 'operations per second'. If I run just one copy of the program it gets a significantly higher rate, as expected since at least one CPU thread can run at the 'boosted' rate. So when I run say 20 threads, they all ran steadily at the 3.3GHz rate. The code uses no floating point, it's super simple and twenty threads seem to run at twenty times the throughput of one (non-boosted) thread.
A month or two ago I noticed that most or all of the processes were dropping to a lower 'rate' of operations after some hours of doing no I/O. I verified this by adding a line of code that writes to the screen every few minutes. Of course this means adding some code very carefully just outside the innermost loop but not so far out that it rarely executes. This is inconvenient because the location of that code varies depending on what the particular program is doing. But if I go to the trouble, it causes the programs to run at 'full speed' again. Minus a tiny bit due to the extra code.
The 'lower rate' is hard to measure exactly but it seems to be less than 10% of normal speed.
I can't say for sure this started happening when I installed Windows 10 but it seems likely. Or it arrived with one of the updates. I can't say for sure that it's limited to console mode programs but it also seems likely, as other programs typically spend a significant amount of their time churning around the Windows API 'idle loop' which is anything but idle and probably trips whatever my screen I/O trips.
All the relevant advanced power options are set to 'allow 100%'. The CPU is not suddenly overheating.
When the programs slow down, Windows Task Manager still says they are running at 5% (the maximum for one of twenty possible threads).
Has anyone else noticed this? I would love to be able to work around it without tailoring my program to bypass an intrusive scheduler.
Update: I'm still looking for an answer to this, but I installed a workaround. In my innermost loop I do a very simple boolean check on a 'break flag'. This adds very little overhead, in fact it was already there to allow keyboard interrupts, a Ctl-Brk enables a keyboard menu. I modified the interrupt routine to distinguish between Ctl-C and CTL-Brk, now Ctl-C sets a flag to say "update the screen with progress then go back to full speed'. Then I wrote a batch file/program that loops every five minutes, and sends a Ctl-C signal to every running program with the correct name. This pretty much allows me to go on as before without worrying about the optimal place to do some I/O to keep things running at full speed. The looping program takes close to zero CPU cycles.
I did some further measurements, it seems that 'average operations per second' falls from around ten million to a thousand or so over a day. So the reduced speed is pretty much stationary by comparison.
Batch file:
:looparound
@echo off
wmic process where "Name LIKE 'cgpuz.exe'" GET ProcessID > procIDs.txt
type procIDs.txt > procIDs.lst
set nump=0
FOR /F "eol=P tokens=1 delims=, " %%i in (procIDs.lst) do ( @set /A nump += 1
@signal %%i 8 )
@echo.
@echo Sent %nump% signals
@timeout /T 250
goto looparound
