4 ms·

This is not just middlebrow dismissal, it's outright wrong. In the AAA world we would love to spend only 3 weeks of an engineer's time to get a 15% speedup. Ser

by jblow 14y ago

This is not just middlebrow dismissal, it's outright wrong. In the AAA world we would love to spend only 3 weeks of an engineer's time to get a 15% speedup. Seriously, that is a great deal, it's like, where do I sign up? However, it becomes substantially less impressive when you notice that you're using 2x or 4x the amount of processor hardware (2 or 4 cores) and only getting a 15% speedup. In a by-hand implementation that would be very disappointing. If it were fully automated that would still be pretty valuable, but it appears that this isn't. So it seems to be of questionable utility.

FrankBooth 14y ago
When were you in the AAA world, Jonathan?
- jblow 14y ago
  I did a lot of consulting / contract work at AAA companies between 2000-2005. "Parachute in and make the E3 demo work / implement some tough feature / etc". Sometimes it was less well-defined than that.
  - confluence 14y ago
    Woah you're the guy that did Braid - glad to see you on HN :D Love to hear more about your 2000-2005 paratrooper work at the AAA shops - have you discussed that at all anywhere? I've always been interested in seeing how the really tough stuff gets done at AAA shops.
    - groby_b 14y ago
      The same way it gets done elsewhere - you find a person who's an expert at that kind of stuff and tell them to get it done :) The parachute-in often happens for teams that don't have a whole staff of low-level engineers around. Either small studios using an off-the-shelf engine (that can still be customized), or studios in a large conglomerate. (EA e.g. used to be quite happy to ship experts around. At least back in my day.)
BlackAura 14y ago
Worse, they didn't actually get a 15% speedup. They reduced the frame time from 16.7ms (around 60FPS) to 15.3ms (around 65 FPS), which is only a speedup of something like 7%. They didn't seem to mention how much they're actually utilizing the remaining cores either. From the look of it, they've basically parallelized a couple of loops in the renderer. That strikes me as being the wrong way to go about this, especially considering that modern AAA games apparently break everything down into tasks, and run the separate tasks in parallel (idTech5 apparently does this, for example).
- to3m 14y ago
  p21 in the white paper suggests the speedup is ~2x, for the parts that were actually parallelized. That's more interesting (well, to me) than the rather limited increase in overall frame rate. You may be right that they are doing the wrong thing, but I think the fact it's doable at all is reasonable evidence that their tool is useful. I'm pretty impressed that somebody who's totally unfamiliar with the code is able to jump in and start parallelizing stuff - particularly if they've never worked on a game before, and so might not have any real idea where would be a good place to start, or how things are likely to work. Maybe my standards are too low. (Those screwy HUD textures might be evidence that they managed to get it completely wrong, of course ;) - or maybe it's just something simple.)
  - BlackAura 14y ago
    Good point. Their tool is obviously useful, even though something like this might not be the best use case for it. The HUD thing - it looks like they screwed up the post-processing effects somehow. As far as I remember, the original game did apply post-processing effects to the HUD. Probably something to do with OpenGL not getting a decent way to do render-to-texture until 2005, so they'd have had to use the previous frame's render buffer. It wasn't that noticeable in the original though.
fons 14y ago
The exercise was more about evaluating what the tool could bring for already-optimized code than about comparing the results against what an expert programmer could achieve manually. It is true that the application domain of the code chosen for the blog post might be a bit unfortunate in order to make a realistic case. Game engine programmers are usually very good at low level optimizations. Pareon can be used by non-experts though and additionally assist experts in during the task of finding and applying optimizations and paralellization oportunities. Quoting the blog update [1]: "Our Pareon tool is not aimed to replace parallelization experts. We want the tool to be useful for any programmer who is looking for paralellization opportunities in either his own code or in code that he is unfamiliar with. A domain expert (game programmer) can probably save some time because of his in-depth knowledge." Additionally: "The three additional cores on my four-core machine are only used during part of a rendering cycle. They are sleeping the rest of the time. If I would parallelize other pieces of code in the cycle as well, it would increase utilization and I would expect the frame rate to improve even more." [1] http://www.vectorfabrics.com/blog/item/accelerating_the_idtech_4_engine_with_pareon_a_follow_up http://www.vectorfabrics.com/blog/item/accelerating_the_idte...

by jblow 14y ago

FrankBooth 14y ago

When were you in the AAA world, Jonathan?

jblow 14y ago
I did a lot of consulting / contract work at AAA companies between 2000-2005. "Parachute in and make the E3 demo work / implement some tough feature / etc". Sometimes it was less well-defined than that.
- confluence 14y ago
  Woah you're the guy that did Braid - glad to see you on HN :D Love to hear more about your 2000-2005 paratrooper work at the AAA shops - have you discussed that at all anywhere? I've always been interested in seeing how the really tough stuff gets done at AAA shops.
  - groby_b 14y ago
    The same way it gets done elsewhere - you find a person who's an expert at that kind of stuff and tell them to get it done :) The parachute-in often happens for teams that don't have a whole staff of low-level engineers around. Either small studios using an off-the-shelf engine (that can still be customized), or studios in a large conglomerate. (EA e.g. used to be quite happy to ship experts around. At least back in my day.)

BlackAura 14y ago

Worse, they didn't actually get a 15% speedup. They reduced the frame time from 16.7ms (around 60FPS) to 15.3ms (around 65 FPS), which is only a speedup of something like 7%. They didn't seem to mention how much they're actually utilizing the remaining cores either. From the look of it, they've basically parallelized a couple of loops in the renderer. That strikes me as being the wrong way to go about this, especially considering that modern AAA games apparently break everything down into tasks, and run the separate tasks in parallel (idTech5 apparently does this, for example).

to3m 14y ago
p21 in the white paper suggests the speedup is ~2x, for the parts that were actually parallelized. That's more interesting (well, to me) than the rather limited increase in overall frame rate. You may be right that they are doing the wrong thing, but I think the fact it's doable at all is reasonable evidence that their tool is useful. I'm pretty impressed that somebody who's totally unfamiliar with the code is able to jump in and start parallelizing stuff - particularly if they've never worked on a game before, and so might not have any real idea where would be a good place to start, or how things are likely to work. Maybe my standards are too low. (Those screwy HUD textures might be evidence that they managed to get it completely wrong, of course ;) - or maybe it's just something simple.)
- BlackAura 14y ago
  Good point. Their tool is obviously useful, even though something like this might not be the best use case for it. The HUD thing - it looks like they screwed up the post-processing effects somehow. As far as I remember, the original game did apply post-processing effects to the HUD. Probably something to do with OpenGL not getting a decent way to do render-to-texture until 2005, so they'd have had to use the previous frame's render buffer. It wasn't that noticeable in the original though.

fons 14y ago

The exercise was more about evaluating what the tool could bring for already-optimized code than about comparing the results against what an expert programmer could achieve manually. It is true that the application domain of the code chosen for the blog post might be a bit unfortunate in order to make a realistic case. Game engine programmers are usually very good at low level optimizations. Pareon can be used by non-experts though and additionally assist experts in during the task of finding and applying optimizations and paralellization oportunities. Quoting the blog update [1]: "Our Pareon tool is not aimed to replace parallelization experts. We want the tool to be useful for any programmer who is looking for paralellization opportunities in either his own code or in code that he is unfamiliar with. A domain expert (game programmer) can probably save some time because of his in-depth knowledge." Additionally: "The three additional cores on my four-core machine are only used during part of a rendering cycle. They are sleeping the rest of the time. If I would parallelize other pieces of code in the cycle as well, it would increase utilization and I would expect the frame rate to improve even more." [1] http://www.vectorfabrics.com/blog/item/accelerating_the_idtech_4_engine_with_pareon_a_follow_up http://www.vectorfabrics.com/blog/item/accelerating_the_idte...