10 ms·

Came for the dismissive hand-waving that I fully expected to be the top comment and I wasn't disappointed. What's the improvement factor where you'd be impress

Came for the dismissive hand-waving that I fully expected to be the top comment and I wasn't disappointed. What's the improvement factor where you'd be impressed? 50%? 60%? It's remarkable in my opinion how little work it took to improve upon an already very-optimized engine, in the constraints that they set for the developer, by a developer who's never worked with game engines in his career. Edit: No longer the top comment; it was when I commented.

kevingadd 14y ago
Framerate isn't a comparative measurement. You have to measure elapsed time. Instead of spending 3 weeks wrapping data structures in mutexes for a 15% framerate increase, you could probably get an equivalent speedup by reducing shader detail, texture size, or any number of other options. This kind of measurement is not meaningful without additional information: Is this improved performance for low-spec GPUs? High-spec CPUs? universal performance improvement for all users? Low end machines typically do not have lots of cores; will they actually benefit tremendously from parallelism? As I said before, a high-spec machine already runs Doom 3 fine, so I question whether the gains here would actually be significant at all. EDIT: Also, gains of this size can easily be produced by changes as simple as turning on Profile-Guided Optimization in your compiler. We'd also need to know what settings they used to compile the game to know whether the results are actually realistic.
- jspthrowaway 14y ago
  > Instead of spending 3 weeks wrapping data structures in mutexes for a 15% framerate increase, you could probably get an equivalent speedup by reducing shader detail, texture size, or any number of other options. I see why we differ in opinion here: you feel that regressing backwards and sacrificing visual quality is a better approach than parallelizing the same exact engine with the same quality. I don't think we're going to see eye-to-eye on this one.
  - kevingadd 14y ago
    PC game development is about delivering a good experience for users on a wide range of hardware configurations. A given game is not going to automatically run perfect on every hardware configuration. When considering performance issues for a particular customer, you have to weigh the cost of improvement. 3 weeks of an engineer's time for 15% speedup (even if it were in elapsed frame time, which it's not) is NOT an easy decision. Those 3 weeks could be spent doing far more valuable things, like improving the tools used by the rest of the development team, fixing crash bugs, or working on downloadable content that will bring in more money for the studio. They could also be spent making architectural changes that provide much larger performance wins through design improvements that require actual knowledge about the design of the application and the significance of the choices made. When you're doing performance optimization in game development, you go for the biggest, cheapest wins first, based on actual measurements and an understanding of what's wrong. Given that the optimized version of the game is not running at 60fps (and the demo video contains obvious rendering glitches) I don't think it's unfair to question whether CPU parallelism was the most obvious bottleneck here. Lastly, dropping texture size or shader detail when running on a low spec machine is not a regression. If the machine is not capable of running at max rendering detail due to GPU constraints, no degree of CPU parallelism will overcome this.
    - jspthrowaway 14y ago
      All of what you say is wise, but the engineer doesn't work for the studio and isn't on Doom 3's release timeline. He made the game's frame rate 15% faster of his own volition simply because he could. So it's wrapped in a sales pitch, oh well. "I see something I can improve, but I had better not improve it; were I to work at id, my time would probably be more valuably spent on other things." I wish you'd just back off and laud the improvement rather than fitting it into your model of game development and continuing to double down on a snarky, dismissive comment that basically shits on somebody else's work. I certainly appreciate that you've worked in professional game development, but come on, someone did something cool. I'm sorry that it isn't cool enough for you or doesn't use the measurements you prefer. Attitudes like yours hurt our industry as a whole.

kevingadd 14y ago

Framerate isn't a comparative measurement. You have to measure elapsed time. Instead of spending 3 weeks wrapping data structures in mutexes for a 15% framerate increase, you could probably get an equivalent speedup by reducing shader detail, texture size, or any number of other options. This kind of measurement is not meaningful without additional information: Is this improved performance for low-spec GPUs? High-spec CPUs? universal performance improvement for all users? Low end machines typically do not have lots of cores; will they actually benefit tremendously from parallelism? As I said before, a high-spec machine already runs Doom 3 fine, so I question whether the gains here would actually be significant at all. EDIT: Also, gains of this size can easily be produced by changes as simple as turning on Profile-Guided Optimization in your compiler. We'd also need to know what settings they used to compile the game to know whether the results are actually realistic.

jspthrowaway 14y ago
> Instead of spending 3 weeks wrapping data structures in mutexes for a 15% framerate increase, you could probably get an equivalent speedup by reducing shader detail, texture size, or any number of other options. I see why we differ in opinion here: you feel that regressing backwards and sacrificing visual quality is a better approach than parallelizing the same exact engine with the same quality. I don't think we're going to see eye-to-eye on this one.
- kevingadd 14y ago
  PC game development is about delivering a good experience for users on a wide range of hardware configurations. A given game is not going to automatically run perfect on every hardware configuration. When considering performance issues for a particular customer, you have to weigh the cost of improvement. 3 weeks of an engineer's time for 15% speedup (even if it were in elapsed frame time, which it's not) is NOT an easy decision. Those 3 weeks could be spent doing far more valuable things, like improving the tools used by the rest of the development team, fixing crash bugs, or working on downloadable content that will bring in more money for the studio. They could also be spent making architectural changes that provide much larger performance wins through design improvements that require actual knowledge about the design of the application and the significance of the choices made. When you're doing performance optimization in game development, you go for the biggest, cheapest wins first, based on actual measurements and an understanding of what's wrong. Given that the optimized version of the game is not running at 60fps (and the demo video contains obvious rendering glitches) I don't think it's unfair to question whether CPU parallelism was the most obvious bottleneck here. Lastly, dropping texture size or shader detail when running on a low spec machine is not a regression. If the machine is not capable of running at max rendering detail due to GPU constraints, no degree of CPU parallelism will overcome this.
  - jspthrowaway 14y ago
    All of what you say is wise, but the engineer doesn't work for the studio and isn't on Doom 3's release timeline. He made the game's frame rate 15% faster of his own volition simply because he could. So it's wrapped in a sales pitch, oh well. "I see something I can improve, but I had better not improve it; were I to work at id, my time would probably be more valuably spent on other things." I wish you'd just back off and laud the improvement rather than fitting it into your model of game development and continuing to double down on a snarky, dismissive comment that basically shits on somebody else's work. I certainly appreciate that you've worked in professional game development, but come on, someone did something cool. I'm sorry that it isn't cool enough for you or doesn't use the measurements you prefer. Attitudes like yours hurt our industry as a whole.