Dyson Sphere Program - Dev Log - The New Multithreading Framework - Steam News
store.steampowered.com
Hello, Engineers! We're excited to share that development of Dyson Sphere Program has been progressing steadily over the past few months. Every line of code and every new idea reflects our team's hard work and dedication. We hope this brings even more surprises and improvements to your gameplay experience! (Vehicle System: Activated!)  Bad News: CPU is maxing out   During development and ongoing maintenance, we've increasingly recognized our performance ceilings.

cross-posted from: https://lemmy.dbzer0.com/post/54512198

There’s a newer post as well that follows up on that first one from June. I’m not super technically versed in things like CPU scheduling but I really like that they shared these posts.

I haven’t played DSP in about a year but these guys have definitely caught lighting in a bottle with this concept. If you’ve played this game, you know how crazy that feeling of finally being able to lift off and just… have the full expanse of outer space open in front of you is.

  • I Cast Fist@programming.devEnglish
    2·
    2 months ago

    Then, any thread that finishes early will “steal” half of the remaining workload from the busiest thread. This loop continues until no thread’s workload exceeds a defined threshold.

    Oh, I didn’t know this was possible with programming. I wonder what such code would look like.

    • mushroommunk@lemmy.todayEnglish
      2·
      18 days ago

      Programmer here. I only skimmed the article but this sort of scheduling is very common in multithreaded applications.

      The most common I see is Thread 1 is the application start. You click game.exe and this is it. This thread does a lot of initialization and prep work.

      Thread 1 then spawns thread 2,3,4,etc and hands them each a set of tasks and a callback function. For DSP it’s probably a list of buildings to calculate resource generation for it seems.

      Here’s where I’m guessing. The array of buildings is shared memory that the main task can monitor. As a thread finishes it’s assigned array, it callsback to the main thread it’s completion, the main thread then quickly scans the threads for the one with the longest list over a certain length (probably to avoid overhead of splitting if there’s only a few items left), takes half of it, and sends it to the idle thread, leaving half in the shared memory for the busy thread.

      Rinse and repeat until all tasks are done.

      The specifics of the code are going to be highly language dependent. Thread locking and instruction atomicity become real important. Hopefully that helps a little.