Yup. always gotta be that one single threaded program. In this case, appears to be frigate.

  • vext01@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    13
    arrow-down
    1
    ·
    1 year ago

    Programming with threads is much harder than using a single thread.

    First your workload has to be split up in such a way that it can be distributed. That’s not always possible.

    The you gotta insert “synchronisation” to avoid a whole class of concurrency issues.

    Hence programmers always default to a single thread unless really needed.

    • shadowbert@kbin.social
      link
      fedilink
      arrow-up
      8
      arrow-down
      1
      ·
      1 year ago

      Of course - I get that. I’m a programmer myself.

      But it does have to be said that there’s little excuse for not doing it anymore for heavy applications, especially games. The tools/frameworks/engines have vastly improved, and people know (at least roughly) ahead of time what work is going to slog the CPU, especially in the case of a AAA studio.

      Note: I’m only referring to relatively modern games here - anything that’s older than when multithread really took off gets an automatic pass - it’s not reasonable to expect someone to cater for a situation that doesn’t exist yet.

      • douglasg14b@lemmy.world
        link
        fedilink
        arrow-up
        5
        arrow-down
        4
        ·
        edit-2
        1 year ago

        there’s little excuse for not doing it anymore for heavy applications, especially games

        … Wut. You chose one of the best examples of where multi-threaded workloads are extremely difficult and often impractical as your example of where it should definitely be used…? 🤦

        Games are where it’s the most difficult, nevermind enterprise workloads that can be multi-threaded on paper, while games can often not even make that work in theory. Game workloads are incredibly, almost insurmountably, difficult to multi-threaded for most teams and studios.

        Not just from a technical standpoint but from a practical standpoint as well as you are significantly increasing the surface area for software defects, full of pitfalls and gotchas. Sure you can multi-thread your workload but now it actually runs slower than it would have if you never did this at all due to increased resource usage as a result of synchronization…etc

        Games like factorio are rarities, where the developers had both a small game and scope, and all the time and resources they needed to produce multi-threaded solutions to their workloads. Engines like unity have ECS, which has limitations of use and comes with extra asterisks. But outside that and a few other examples actual multi-threading is a massive undertakings that may actually mean your Game cannot be delivered.

        • shadowbert@kbin.social
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          Difficult, yes. Impractical? Absolutely not, at least with some planning ahead. It’s not trivial (and I never said it was) but it’s getting both easier and more important every year.

    • deleted@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      1 year ago

      I’m programmer myself and I understand that it’s not simple even though you can use blocking or protected collections.

      I’m referring to a situation where the programmer made a function multithreaded but hard coded creating only 4 threads “to fully utilize a 4 core cpu”