4 ms·

The author is worried about optimizing. He should know that in high-performance applications, you should just write the code then profile it. We all know that C

by psyklic 17y ago

The author is worried about optimizing. He should know that in high-performance applications, you should just write the code then profile it. We all know that C++ is fast; the real question the author should be asking is whether C or C++ can more quickly express ideas/is more maintainable/etc. This post about not knowing how a function is called is really splitting hairs, bordering on irrelevant imo -- sure, it can affect the time taken to call a function by ten times, but this is not a large performance hit at all for 95% of your code, and even less since most high performance items are on the GPU. If it ends up that it does affect performance in a critical area (found via profiling), the author even suggested how it can easily be fixed. I don't see what the big deal is. If you're a game programmer, change your coding conventions so that you don't get into problems like this.

groby_b 17y ago
She does know that you need to profile, TYVM. But ideally, you pay at least cursory attention to performance even when you write the code. Writing code with complete disregard to performance, saying "oh, the profiler will find it" is not an acceptable choice. You don't write sloppy code and argue that you can find bugs in the debugger, either, do you? And no, most high-performance items are not on the GPU. Most games are already GPU-bound, so you want to take load off of it. (Also, with the arrival or LRB et al., the GPU/CPU distinction becomes moot) If those issues were irrelevant, I wouldn't care about them. There's one thing I do care about: Shipping high quality games, developed as fast as possible. C++ hurts that goal. And no, the 95%/5% rule does not hold true in game development. But don't trust me - read, for example, Tim Sweeny, the guy behind the Unreal engine. According to him, there are not hotspots. Another Unreal programmer: http://lambda-the-ultimate.org/node/1277#comment-14238 http://lambda-the-ultimate.org/node/1277#comment-14238 "Dan Vogel, was fond of pointing out that UE2 had a basically flat profile" That is the big deal. In a flat profile, things like calling overhead matter everywhere.
- psyklic 17y ago
  Worrying about not knowing how functions are called on your first iteration is such a moot point. Simple programming conventions (e.g. no multiple inheritance) can eliminate this problem. Even if each function call does take 10x longer, I would argue that in 99% of the cases you wouldn't even notice the difference, practically speaking. Shipping high quality games, developed as fast as possible. If this is what you care about, then you should care about optimizing AFTER you write the initial version and identify hot spots. You don't write sloppy code and argue that you can find bugs in the debugger, either, do you? Sloppy code vs. "slow" code are vastly different. I would much much rather have slow code, since 99% of the time it isn't even noticed by the user. Hence, it was worth not thinking about how to improve it. most high-performance items are not on the GPU. I agree that you want to take load off the GPU. However, CPU speed has not been the limiting factor in games for a LONG time. In fact, in conferences such as the GDC it is rarely discussed any longer, only in the context of using more CPU if available for non-engine tasks such as AI. And no, the 95%/5% rule does not hold true in game development. There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game. If you look at modern games, do you think it is a waste that they are based on interpreted scripting languages? They can do this because as I said above, CPU isn't as limiting a factor as before.
  - groby_b 17y ago
    _Sloppy code vs. "slow" code are vastly different._ Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues. While you can optimize them after the fact, it's more time you're spending. _CPU speed has not been the limiting factor in games for a LONG time_ Yes, actually, it is. It might not be raw speed - we're talking cache misses instead - but you still have to be careful with your resource usage. _There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_ Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-Engine http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-En... And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well. But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top. The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world. So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.) If you look at modern games, I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)

by psyklic 17y ago

groby_b 17y ago

She does know that you need to profile, TYVM. But ideally, you pay at least cursory attention to performance even when you write the code. Writing code with complete disregard to performance, saying "oh, the profiler will find it" is not an acceptable choice. You don't write sloppy code and argue that you can find bugs in the debugger, either, do you? And no, most high-performance items are not on the GPU. Most games are already GPU-bound, so you want to take load off of it. (Also, with the arrival or LRB et al., the GPU/CPU distinction becomes moot) If those issues were irrelevant, I wouldn't care about them. There's one thing I do care about: Shipping high quality games, developed as fast as possible. C++ hurts that goal. And no, the 95%/5% rule does not hold true in game development. But don't trust me - read, for example, Tim Sweeny, the guy behind the Unreal engine. According to him, there are not hotspots. Another Unreal programmer: http://lambda-the-ultimate.org/node/1277#comment-14238 http://lambda-the-ultimate.org/node/1277#comment-14238 "Dan Vogel, was fond of pointing out that UE2 had a basically flat profile" That is the big deal. In a flat profile, things like calling overhead matter everywhere.

psyklic 17y ago
Worrying about not knowing how functions are called on your first iteration is such a moot point. Simple programming conventions (e.g. no multiple inheritance) can eliminate this problem. Even if each function call does take 10x longer, I would argue that in 99% of the cases you wouldn't even notice the difference, practically speaking. Shipping high quality games, developed as fast as possible. If this is what you care about, then you should care about optimizing AFTER you write the initial version and identify hot spots. You don't write sloppy code and argue that you can find bugs in the debugger, either, do you? Sloppy code vs. "slow" code are vastly different. I would much much rather have slow code, since 99% of the time it isn't even noticed by the user. Hence, it was worth not thinking about how to improve it. most high-performance items are not on the GPU. I agree that you want to take load off the GPU. However, CPU speed has not been the limiting factor in games for a LONG time. In fact, in conferences such as the GDC it is rarely discussed any longer, only in the context of using more CPU if available for non-engine tasks such as AI. And no, the 95%/5% rule does not hold true in game development. There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game. If you look at modern games, do you think it is a waste that they are based on interpreted scripting languages? They can do this because as I said above, CPU isn't as limiting a factor as before.
- groby_b 17y ago
  _Sloppy code vs. "slow" code are vastly different._ Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues. While you can optimize them after the fact, it's more time you're spending. _CPU speed has not been the limiting factor in games for a LONG time_ Yes, actually, it is. It might not be raw speed - we're talking cache misses instead - but you still have to be careful with your resource usage. _There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_ Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-Engine http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-En... And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well. But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top. The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world. So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.) If you look at modern games, I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)