🌌 Multithreading Setup Guide
In this update, we have completely rebuilt the multithreading system and provided multiple options for players to customize their threading strategy. These options can be adjusted through the [Deep Profiler] (accessible from Performance Test (CPU), click the [Deep Profile] button), or in the Advanced Multithreading Settings under the [Settings]-[Gameplay].
During the testing phase, many players felt uncertain about how to configure the multithreading system. Below, we'll share some commonly used setup plans.
For players who don't want to tweak too much, the default settings are usually fine. However, if the default setup causes some stuttering, you can try the following configuration instead:
● Main Thread Binding Strategy: System Automatic Allocation
● Worker Thread Binding Strategy: Can Use Any Available Core
● Thread Frame Waiting Strategy: Mixed Waiting
● Thread Phase Waiting Strategy: Mixed Waiting
This setup is highly versatile and works well for most situations.
Now let's look at some more advanced setup plans:
🎨 Standard Architecture: Refers to CPUs without a distinction between performance and efficiency cores.
If you are aiming for better game performance, you can try:
● Main Thread Binding Strategy: Binds First Physical Core (Shares)
● Worker Thread Binding Strategy: Each Thread Binds Each Logical Processor in Turn
● Thread Frame Waiting Strategy: Mixed Waiting
● Thread Phase Waiting Strategy: Mixed Waiting
If you often run multiple applications at the same time and need to reserve performance for them, you can try:
● Main Thread Binding Strategy: Binds First Physical Core (Shares)
● Worker Thread Binding Strategy: Each Thread Binds Each Core except the last
● Thread Frame Waiting Strategy: Mixed Waiting
● Thread Phase Waiting Strategy: Mixed Waiting
🔡 Hybrid Architecture: Refers to CPUs that distinguish between performance cores and efficiency cores.
If you are aiming for better game performance, you can try:
● Main Thread Binding Strategy: Binds First P-Core (Shares)
● Worker Thread Binding Strategy: Each Thread Binds Each P-core or Two E-cores in turn.
● Thread Frame Waiting Strategy: Mixed Waiting
● Thread Phase Waiting Strategy: Mixed Waiting
If you often run multiple applications at the same time and need to reserve performance for them, you can try:
● Main Thread Binding Strategy: Binds First P-Core (Shares)
● Worker Thread Binding Strategy: Each Thread Binds Each Core Except the last
● Thread Frame Waiting Strategy: Mixed Waiting
● Thread Phase Waiting Strategy: Mixed Waiting
Above are general-purpose setups, but depending on your hardware, actual performance may vary — they are not guaranteed to be optimal.
Of course, for hardcore players who want to fine-tune and find the strategy that works best for them, we've also developed the Custom Core binding Feature. This allows players to configure CPU core binding strategies for each individual thread.
You can find this feature in the Advanced Multithreading Settings. By setting the Thread Binding Strategy to Custom Core Binding, you will be able to modify the binding for each thread.
For example:
Worker Thread Mask 00 means you are editing the settings for Worker Thread 00. [0] 11000000 0000 is the mask. [0] is the thread group(this is usually set to 0, unless the thread count exceeds 64).
The binary mask after that indicates the logical processors for this thread: 1 means it can run on that processor, 0 means it cannot.
In this example, Worker Thread 00 is allowed to run on the first and second logical processors(CPU0 & CPU1), but not on the others.
This configuration can also be accessed through the [Deep Profiler], by clicking into each thread for settings.
For players who want to further understand each option, we've also included detailed explanations for every setting inside the Advanced Multithreading Settings. Players can reference these notes while experimenting with their configurations.
🌌 Technical Overview
During previous development and maintenance, we felt that the program's performance had reached its limits. If we implement the Vehicle System in the future, the game may need to simulate thousands of additional components, far beyond the capacity of the old multithreading system.
The old multithreading system had some major flaws by design: it supported very few task types, had high synchronization overhead at each stage, and splitting logic into forced multithreading often brought little performance gain while adding high maintenance costs. Hastily converting logic to multithreading could result in minimal performance improvement, while dramatically increasing code complexity.
That's why we've recently carried out a complete overhaul of Dyson Sphere Program's multithreading system, paving the way for the upcoming Vehicle System. Here's a closer look at the key features of this brand-new system.
1.Customizable Core Binding: In the old system, threads were automatically assigned by the operating system, a "black box" mechanism that often led to inefficient CPU utilization. Now, players can manually assign threads to cores, eliminating performance waste caused by system scheduling.
(Multithreading Strategy Customization Panel)
2.Dynamic Task Distribution: Tasks are now evenly distributed across threads, and once a thread finishes its share, it can assist with tasks from other threads until the workload is balanced.
(Even if one thread starts slower, nearly all threads now finish at the same time)
3.More Flexible Framework Design: We are no longer limited to "one task type per multithreading stage." Instead, logic can be broken into multiple tasks and flexibly combined, enabling "multi-task per stage." This flexible framework allows running multiple tasks in parallel; offloading logic that was previously locked to the main thread into other facilities' logic; pairing non-distributable tasks with distributable ones, making better use of idle CPU cycles.
(Flow Monitors, Sprayers, and Logistics Station belt outputs running in parallel now take less than 0.1ms in total)
4.Multithreading Communication & Waiting Mechanism: The new system uses much faster spinlocks (~10ns) to link tasks, combined with a hybrid spin–blocking model: Spinlocks for very short execution times; and blocking locks for longer CPU-intensive tasks. This minimizes the response delay between one task ending and the next starting.
(New multithreading wait times are clearly shorter than the old system )
5.Brand-New Performance Profiler: Since the game’s core logic has been completely restructured to allow multiple task types to run in parallel, we’ve also developed a brand-new performance analysis tool.This profiler clearly shows how the new logic operates and how efficient it is.
The above is the interface of the Deep Profiler: The horizontal axis represents game runtime. Each row corresponds to a specific thread’s workload per frame. This tool helps players understand the inner workings of their CPU in real time.
The above is excerpted from our earlier devr log on the multithreading system update. For more details, you can check it out here:
In the gaming community, you never know what surprises players will bring. During the public test, one player shocked us by running the multithreaded version of DSP on a Threadripper CPU!
Not only was it jaw-dropping, but it also brought us valuable feedback: our game didn't seem to support more than 64 threads. We quickly located and fixed this "happy problem."
But the story doesn't end there! Facing such high-end hardware, we ran into another problem—our team didn't have such a "god-tier" equipment to test on. So, we made a bold decision: shamelessly asking the player if we could "borrow" his CPU power for a round of benchmarking.
(Performance on a 680W Universe Matrix Save)
From the screenshot, the game didn't show much difference compared to consumer-grade CPUs. After some probing, we found the reason: the player's memory was DDR4-2666. The bottleneck was most likely the memory!
So the big question is: how do we optimize further? And what platform should we use to validate those optimizations?
Just as we were at a loss, we reached out to AMD. To our delight, they generously offered us a beast of a machine: a Threadripper PRO 9985WX system!
The specs alone are thrilling: 64 cores, 128 threads; Base clock 3.2 GHz, boost up to 5.4 GHz; Support for up to 8 memory channels. This is the ultimate testing platform tailor-made for us!
😿 Unfortunately, due to typhoon delays, this monster is still on its way to us. Please join us in waiting patiently for the unboxing moment!
Once the "beast" arrives, we'll immediately begin in-depth optimization and testing on this extreme hardware. And if you're a Threadripper owner yourself, stay tuned—the optimizations we're preparing for you are coming soon! (Of course, consumer-grade CPUs will also see performance improvements.)
🌌 Notes and FAQs
Q: What should I do if I encounter a bug?
A: If you run into bugs, please first make sure your game is in a clean (unmodded) state. We suggest removing all mods and restarting the game before checking again.
If the bug still occurs in a clean environment, please report it in the #bug-report channel on our Discord. Our team will review and address the issues as soon as possible.
Q: Can old saves work seamlessly with the new multithreading system?
A: Yes. Old saves can be loaded directly in the new version — no need to start a new game. But we still highly recommend backing up your files before updating—just in case.
Default save location (if unchanged):
%USERPROFILE%\\Documents\\Dyson Sphere Program\\Save\[/i]
Q: Will my existing Mods still work?
A: Since this update completely overhauled the core logic of the game, with major code changes, most Mods will conflict with the base game.
If you've been using Mods, we strongly recommend backing up your saves and Mods before updating. Also, make sure your game files are unmodified during the update, otherwise unexpected errors may occur.
Q: What kind of performance boost should I expect? How can I feel it?
A: The main improvement is in the CPU's "game logic frame" time. As shown in the dev log, there is a noticeable boost in logic frame performance. If your save contains large factories or intense combat, the difference will be more noticeable.
Q: What if the game feels laggier after I adjusted the multithreading settings?
A: First, try resetting everything to the default settings (including the ratio between logic frames and render frames). You can also check our setup guide for more options. If you're aiming for even better performance, feel free to join our official Discord server to discuss with other players and admins to find the best configuration for your hardware.
Q: Why does the execution time of logic frames look longer after the update compared to before?
A: For saves that were already running very smoothly (logic frame execution time under 5ms), the reported values may appear slightly higher with the new system. But as long as it stays around 5ms, there will be no difference in actual gameplay experience. The real improvement is seen in heavier cases (when logic frames drop below 60 FPS and execution time goes above 8ms). In those situations, the new system delivers a significant boost.