[2.1.7] Sometimes on loading save cores don't park properly on 9950X3D

[fi5hii]

Since 2.1 control behaviors have been different between launching the same save over and over. this is especially visible on a 9950X3D cpu since CCD1 doesn't have the extra L3 cache. It happens randomly on a save load, it either parks CCD1 properly and the game runs only on CCD0 like it should but sometimes it runs on both CCDs resulting in 300% higher time for control behaviors. This wasn't an issue in 2.0 where it always properly parked CCD1.

This might have something to do with window focus because when you click out of any game it temporarily runs it on all cores then clicking back in runs it back on only CCD0. It might have to do something with microsoft's Game Bar as well because that's how the driver figures out what is a game and what process should be ran on which CCD.

Here's a video of this happening with the CPU graph included:

2026-06-24 13-02-33.mp4

(31.65 MiB) Downloaded 12 times

factorio-current.log

(10.45 KiB) Downloaded 5 times

[Techjar]

Yeah this just sounds like Windows scheduler fuckery. One of the reasons Linux is known to be better for Factorio.

[Rseding91]

Yeah this just sounds like Windows scheduler fuckery. One of the reasons Linux is known to be better for Factorio.

Linux users are also seeing this exact same problem.

[Techjar]

Linux users are also seeing this exact same problem.

Ah, very interesting then. The apparent window focus behavior just made me think it was a Windows thing, since Windows does have a system for prioritizing the focused task over others. Still Factorio isn't really in control of which cores it gets scheduled on, right? I wonder what sort of behavior would be causing the sub-optimal scheduling.

[fi5hii]

Ah, very interesting then. The apparent window focus behavior just made me think it was a Windows thing, since Windows does have a system for prioritizing the focused task over others. Still Factorio isn't really in control of which cores it gets scheduled on, right? I wonder what sort of behavior would be causing the sub-optimal scheduling.

I was mainly just throwing out ideas what could cause this and my knowledge on how the core parking works for this CPU. One more thing to note tho is when the cores are parked properly and I just go out of focus the control behaviors time only goes up by like 50% when running on all cores and when tabbing back in, it resumes as normal so it's probably not windows focus mode? It is weird that is happens at the load save stage tho not at the game open stage.

Mainly wanted to post this on the forums as well in case anyone else has the issue and to get any updates if it's uncovered why this is happening now in 2.1

[fi5hii]

I also just tested it on mac, does the same thing but not as big of a difference, I'm guessing because the cpu is much slower in general (M2 Pro chip) control behaviors go at lowest to 0.700 and when it bugs out to 0.930 ish. Both happens in windowed and fullscreen modes. Just trying to accumulate as much info as possible into this thread.

[abucnasty]

I spent some time digging into this over the last week on my machine which is a 9800X3D and on linux. Since my CPU doesn't actually have core parking, I think the issue is an underlying threading issue in the `ControlBehaviorManager::update` branch. The full details and benchmarks I ran are here: https://github.com/abucnasty/factorio-b ... g-in-2-1-6

My biggest take away from this is that the control behavior update time is constant and the performance is determined on each save load. If you remove entities or add them back it doesn't matter as the control behavior will either be elevated or it will go back to 2.0.77 levels. Only when you reload the save file do you roll the dice on what you are going to get.

The control behavior is a strict bimodal distribution being either "fast" like 2.0.77 or "slow". The amount of entities in the save file directly correspond with how much the bimodal distribution amplitude will be.

Tests:

- mimalloc vs malloc
- mimalloc with huge pages
- locking to specific cores
- enabling the update-runner-threads-count=1 (only thing that actually remove the inconsistency)
- disable ASLR