   Console development - first in a new series of articles
  I've decided to start a blog on some of the common industry practice for console development that it seems to me is not well known outside of the games industry. Much of this information is already out there on the web if you look hard enough but is spread across posts to mailing lists and forums and I haven't seen it collected in one place with the aim of communicating the information to programmers who might be considering trying to get into the industry.The first two posts are a two part article, an introduction to the major differences between PC and console development: Part 1 and Part 2. These articles are a fairly high level overview, in future articles I intend to drill down more into technical details. The intended audience is programmers with some existing knowledge of game development, perhaps hobbyist programming on the PC, who would like to learn more about industry practice for console development.I'd be grateful for feedback on the style, tone and content and on whether there's interest in me continuing the series. Other feedback on the presentation of the site or anything else is also welcome. This is my first attempt at writing anything like this so any feedback will be useful.   
  The style was very easy to read, and understand :). However it was so general/high level/basic, there was nothing all that interesting in the article. Perhaps you should focus a bit more on a particular topic and get into the nitty gitty of it. I know these are introductory articles, but they should a little bit more meat on them, and the first two should be combined.Also, question for ya :PQuote:The compilers available to console developers, particularly early in the lifetime of a console, will generally have a particularly tough time dealing with more complex C++ constructs: features like templates, exception handling and virtual functions are often relatively more costly on a console than on a PC. This is partly a function of less mature compilers and partly a result of the relative performance of the console CPUs when dealing with some of the code constructs commonly used to implement these C++ language features. Historically it was not uncommon for the compilers available on consoles to not even support many C++ features, though more recent consoles usually have fairly complete support for the C++ language but with particular features having a higher than normal performance cost.Where does the run-time overhead of templates come from ? ;Quote:Original post by MrMarkThe style was very easy to read, and understand :). However it was so general/high level/basic, there was nothing all that interesting in the article. Perhaps you should focus a bit more on a particular topic and get into the nitty gitty of it. I know these are introductory articles, but they should a little bit more meat on them, and the first two should be combined.Yeah, I was trying to find the right balance between breadth and depth and the introductory article doesn't go into much technical detail. Hopefully future articles in the series that go into more depth on particular areas will address that. As for combining the two articles in one, the only reason they are split up is because I wrote it in two parts - it's an artifact of the blog format as much as anything. If you think they'd read easier as a single article that would be an easy change.Quote:Where does the run-time overhead of templates come from ?The biggest performance problem I've seen with template use is that they seem to give the optimizer a hard time on many console compilers. Part of the problem is that a lot of template heavy code is often written with deep nesting of fairly short functions (most STL implementations are written this way if you look at them) and console CPUs tend to suffer more from function call and branching overhead than modern PC processors. Sometimes code that should be efficient ends up being quite slow due to the compilers failing to effectively inline everything that you would expect to be inlined. Due to the lack of maturity of the compilers they sometimes miss 'obvious' optimizations in templated code as well and generally benefit from more hand holding than you'd expect from PC compilers.An example of the kind of thing I'm talking about is a math library I worked on for PC, 360 and PS3 that used templates quite heavily. C++ code that compiled down to fairly optimal assembly on the PC and 360 ended up very slow on the PS3 because the PS3 compiler at the time did a poor job of inlining, particularly when templates were involved. In the end much of the code had to be rewritten to use macros instead of inline functions and templates in order to get good performance on the PS3, something that shouldn't be necessary with a mature compiler and that wasn't necessary on the PC.   ;"PC developers are commonly advised to trust the compiler to do a good job of optimizing their code and to focus on algorithmic optimizations rather than low level optimizations."This is true for both PC and Console developers.  Performance-conscience PC developers constantly analyze generated assembly code, profile their binaries through applications like VTune, find CPU/Memory/Vidcard throughput bottlenecks, etc etc.  Console developers also have to make good choices on algorithms;  low level optimizations do not always save particularly crappy algorithms.So in this regard, I see very little difference between PC and Console developers.  A potential advantage that console developers have is that the low-level optimizations can get highly platform-specific, whereas PC developers may need to check whether or not the running CPU supports a particular feature before taking advantage of it (for example, SSE/2 code).Most (most) non-Win32 platforms use the GCC compiler, which has been tried-and-true for years."One bright spot in the tool situation on consoles is that developers usually have access to very comprehensive and sophisticated performance profiling tools, particularly once the console platform is established and has had a few years of development effort dedicated to its tool set."Actually, Win32 development tends to win out on this one.  In every console project I've worked on we've had to make our own profiling tools from scratch - instrumenting profilers, memory throughput monitors, texture swap managers, etc etc.These are just my experiences on the platforms I've worked on.  Your statements may be true for the platforms you've been witness to.  What I'd suggest is examples to back up your points (ie, which compiler is used for Wii dev, Wii CPU vs 360 COU vs PS3 CPU(s)), and even perhaps even analyze a specific platform at a time.   ;Quote:Original post by GrafalgarThis is true for both PC and Console developers.  Performance-conscience PC developers constantly analyze generated assembly code, profile their binaries through applications like VTune, find CPU/Memory/Vidcard throughput bottlenecks, etc etc.  Console developers also have to make good choices on algorithms;  low level optimizations do not always save particularly crappy algorithms.It's true that algorithmic optimizations are important on consoles and also true that low level optimizations can be valuable on the PC. In my experience though the low level optimizations tend to have a bigger overall impact on consoles - the in order PowerPC CPUs on the 360 and PS3 are much more sensitive to the quality of code produced by the compiler than a Core 2 or other modern PC processor for example. I plan to talk in more detail about those issues, to the extent that I can do so without risking breaching any NDAs, in later posts. Obviously it's not a totally black and white distinction but generally speaking console developers have to be more aware of what the compiler is doing with their code and what impact that has on performance than PC developers.Quote:Most (most) non-Win32 platforms use the GCC compiler, which has been tried-and-true for years.Well, given that none of the Xbox 360, PS3 or Wii currently have GCC as the primary officially supported compiler I'd say that's not true for consoles today. Even when GCC is the main supported compiler, it's usually been customized for the special features of the console's CPU and doesn't have code gen as good as you might expect from the main line x86 version of the compiler. Optimal instruction scheduling requires detailed specs for the specific variant of the CPU as well and using a generic PowerPC back end on the 360 or PS3 will produce working but not particularly optimal code for example.Quote:Actually, Win32 development tends to win out on this one.  In every console project I've worked on we've had to make our own profiling tools from scratch - instrumenting profilers, memory throughput monitors, texture swap managers, etc etc.These are just my experiences on the platforms I've worked on.  Your statements may be true for the platforms you've been witness to.  What I'd suggest is examples to back up your points (ie, which compiler is used for Wii dev, Wii CPU vs 360 COU vs PS3 CPU(s)), and even perhaps even analyze a specific platform at a time.I'd like to provide more specific examples but I'm wary of NDA issues. The Xbox 360 performance tools have been discussed in a public presentation here though and are an example of the kind of thing I'm talking about - trace recording as discussed in that presentation in particular is an example of the kind of detailed information that isn't generally avaiable on the PC. I think it's fairly public knowledge that the Xbox and Xbox 360 versions of PIX are quite a bit more sophisticated than the PC version as well. Sony provides similar sophisticated profiling tools for their platforms but I don't think the information is in the public domain.;Quote:Original post by MrMarkThe style was very easy to read, and understand :). However it was so general/high level/basic, there was nothing all that interesting in the article. Perhaps you should focus a bit more on a particular topic and get into the nitty gitty of it.I've posted a new article on asset pipelines which hopefully has a bit more technical meat on the bone: http://www.mattnewport.com/blog/2008/03/asset-pipelines.html;Quote:Original post by Grafalgar...whereas PC developers may need to check whether or not the running CPU supports a particular feature before taking advantage of it (for example, SSE/2 code)...I think it is funny that so many people get stuck on just SSE (Pentium 3) or SSE2 (Pentium 4).What about SSE3, on both Intel Core and AMD X64 processor?  Or SSSE3, on all Core 2 and many AMD chips?  Or how about SSE4, available on the very latest rounds of Core 2 processors?Finally, SSE is overrated for many uses. The relatively high cost of state changes can overwhelm the relatively low benefit of the operations.  Don't just blindly jump in to SSE and assume things are faster.  Profile before and after, and make sure that it really does improve your performance.Quote:It's true that algorithmic optimizations are important on consoles and also true that low level optimizations can be valuable on the PC.I've worked on the broad spectrum from cutting-edge multiprocessing devices down to 12-MHz machines.  Algorithmic optimizations are by far the best way to go.  Do them first, after measuring.  Next, if your measurements say it is necessary, find ways to reduce or eliminate branching, inline highly-used functions (but don't inline infrequently called or large functions),  and improve general memory access patterns. If your hardware supports them, take advantage of non-branching conditionals and branch prediction improvements. If, after measuring, you find you still need better performance and you are using the absolute best algorithm, go through every implementation detail and perform your strength-reducing, cache-improving, and general hardware-specific improvements.  Of course, at this step you should be careful to profile before and after, ensuring that your performance changes are significant.  Also at this step, you should be reviewing the actual assembly output of your optimized builds.  I can count the number of times I've needed to go to this level on one hand.There are very few things that need to be hand-written in asm, and in those very few cases you can generally find something on the vendor's libraries, newsgroups, or discussion boards.  These generally include the lowest level matrix and graphics routines that are potentially called hundreds of thousands of times per second.  Writing the low level asm yourself (unless you are completely expert on the timings and inner workings of the specific processor) is almost always a bad move.  In every case (except one, noted below) where a co-worker has written asm code, I have always been able to write C or C++ code that outperforms it when we compare profile results, and I've been doing this for over a decade.  Usually I am able to write the higher level code (which performs better) in less time, so it is a big win for the game generally.The single exception was a co-worker who was hired specifically for hand-tuning the low level graphics, done while I was still in graduate school.  He knew the hardware, and could ramble in detail about the specific timings of different operations, how to order the instructions so they go through the cache in the optimal way, and wrote code that was incomprehensible to most mortals.  His code was generally only a few percent faster and took much longer to write and test, but that was all that was needed.  The code was not maintainable, and was thrown away when we started the sequel.Fortunately, people like him have all moved on to driver-level development.   