[kevingadd]

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]

> 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]

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]

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]

This article is clearly trying to sell licenses for a commercial product based on unsupported, possibly deceptive claims. I don't laud that. If the goal here is to prove the value of this analysis software, they should be proving it in terms of the value it will produce for an actual company developing software - if they're proving value for a game studio, it should probably be in the context I provided above. For other kinds of developers, maybe they have infinite time and their constrained resource is engineer knowledge - in that case this software could be valuable. But you don't demonstrate that using video games.

Hacker News isn't about selling things to managers who make purchasing decisions by lying to them, last time I checked.

[jspthrowaway]

Oh, now they're lying? Care to back that one up? That's a steep accusation that you should probably reconsider attaching to your name.

They wrote a tool to find things to parallelize. They parallelize them, the code gets faster. I realize that it isn't the faster you would prefer, but they picked an accessible target that everybody could understand. It isn't as cool if they say "we made Excel render graphs 15% faster" or "we made MP3 transcoding 15% faster". They just made a code base faster using their tool, that's all.

If they had made a video editor faster and you'd worked on video editors all your life, I'm sure you'd be here shitting on the achievement as well. They're not a game development shop. They picked a game to screw around with. They made it quicker. It just happens to be your pet area, so you absolutely cannot stand that someone figured out how to do something in your little world that you wouldn't think of.

I'm impressed you've upgraded to outright calling them liars now rather than just admit, maybe, you might be wrong.

[taligent]

> He made the game's frame rate 15% faster of his own volition simply because he could.

This isn't some lone engineer's noble cause. This is a sales product demonstration.

> Attitudes like yours hurt our industry as a whole.

No it doesn't. People SHOULD be critical of demonstrations like these because they are rarely representative of real world behaviour.

[jspthrowaway]

People who have never used software should be critical of "here's what our software can do with inexperienced hands, maybe you'll do better"? I'd much rather default to giving benefit of the doubt than assuming everything sucks before I've even touched it. Reminded of people who say they don't like exotic food but have never eaten it.

I think the lowest opinion on the totem pole is one formed by assumptions (based upon personal experience with an area) used to reflect upon something from the hip. "I'm pretty versed in game development, and what these people are doing is stupid based on my world view."