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.
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.
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.
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.
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.
Tend to agree that these massive studios should have the resources.
… 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.
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.
Programmers mostly don’t know how to make multithread programs.
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”