3 ms·

With 8 cores and (I would imagine) much more dev time put into optimization than your typical software, I don't see that as an issue really. Most home computer

With 8 cores and (I would imagine) much more dev time put into optimization than your typical software, I don't see that as an issue really. Most home computer software is still single-threaded, so it makes sense a single core would need to be more powerful in that scenario. Although, I guess maybe my argument is moot since your average home PC CPU is going to have at least 4, probably more, cores...

torginus 4y ago
Imo, the more complex the code, the more difficult to make it run multithreaded. Typical gameplay code, that potentially touches everything every frame, and can be changed on the designers whims, is typically very difficult to scale across codes. For example, Dwarf Fortress is one of the most complicated games of all time, and the creator wrote about how he kept to just running it on 1 core.
- bayindirh 4y ago
  When you're starting from scratch, designing for multiple threads is relatively easy. When you're iterating on a previous design or your best practices from previous projects, it becomes very hard, because you need to move/refactor/redesign/reimplement a lot of code. On top of that, you need to test it, which means it's much more time consuming.
  - torginus 4y ago
    >When you're starting from scratch, designing for multiple threads is relatively easy. It's not. Gameplay code changes constantly and always touches a ton of systems, it's very hard to parallelize, and load balance between cores. I'd be surprised if any complex modern game had multithreaded gameplay code, and even if they do, it's usually some common, but CPU intensive problems, like pathing that gets parallelized. Additionally, I found that most people don't have the skillset to write correct multithreaded code in any capacity, and even those that do frequently introduce hard to detect bugs, in addition to being a huge mental overhead. It's even harder to make performance gains using multithreading. Let's say I multithread my code, but the additional complexity, and synchronization makes my code run at 60% the original speed. On 2 threads, I'm running at 120% speed. It would've been much easier to keep my code on 1 thread, and invest the mental energy to make the code 20% faster there.

torginus 4y ago

Imo, the more complex the code, the more difficult to make it run multithreaded. Typical gameplay code, that potentially touches everything every frame, and can be changed on the designers whims, is typically very difficult to scale across codes. For example, Dwarf Fortress is one of the most complicated games of all time, and the creator wrote about how he kept to just running it on 1 core.

bayindirh 4y ago
When you're starting from scratch, designing for multiple threads is relatively easy. When you're iterating on a previous design or your best practices from previous projects, it becomes very hard, because you need to move/refactor/redesign/reimplement a lot of code. On top of that, you need to test it, which means it's much more time consuming.
- torginus 4y ago
  >When you're starting from scratch, designing for multiple threads is relatively easy. It's not. Gameplay code changes constantly and always touches a ton of systems, it's very hard to parallelize, and load balance between cores. I'd be surprised if any complex modern game had multithreaded gameplay code, and even if they do, it's usually some common, but CPU intensive problems, like pathing that gets parallelized. Additionally, I found that most people don't have the skillset to write correct multithreaded code in any capacity, and even those that do frequently introduce hard to detect bugs, in addition to being a huge mental overhead. It's even harder to make performance gains using multithreading. Let's say I multithread my code, but the additional complexity, and synchronization makes my code run at 60% the original speed. On 2 threads, I'm running at 120% speed. It would've been much easier to keep my code on 1 thread, and invest the mental energy to make the code 20% faster there.