4

I'm a C++ developer using VS 2012 and VS 2010 for developing AAA titles. I have read about not using STL and other stuff provided in the standard headers that come with VS. I read most of the stuff on the websites based on game programming and some are really from the people well known in the industry. I have seen cases where they wont even use vector, list, map and others and not even use utility functions and algorithms. In such cases they write those containers and stuff themselves which has almost the same interface and so much of debug and implementation time spent on such huge code.

I have two questions:

1: Isn't the C++ implementation that comes with VS optimized for the platform for better performance? Isn't it using some intrinsic functions that people on the client end doesn't know about and supplying their own implementation would indeed be more slower in basic container operations such as insert, remove, find, swap, copy? Lets assume that we supply our own custom allocators for faster memory management to every container that we use. Also, they take care of fragmentation, alignment and stuff. Why develop custom containers with almost same interface, why not spend that time on writing allocators and other stuff that might actually help?

2: There are times when we include a lot, a lot, of unnecessary stuff through the standard headers in a huge code base. Unnecessary, because we only needed a thing or two from such huge headers including other huge headers and so on. Now, I know templates aren't instantiated unless used, same goes for the members functions inside them and blah blah. Since, these are precompiled headers, it is safe to assume that there is no compile time hit for that unnecessary stuff. My question is, is there any hidden effect of such inclusions on code size (executable) that grows with the huge growth of the code base? In my opinion there shouldn't be, but I wanna know I'm not mistaken just in case.

Thanks

  • 5
    Plenty of games use the standard library. EA even wrote their own version of it. This seems very opinion based to me. – Retired Ninja Feb 06 '15 at 05:16
  • I think I would not use iostreams in a game, just because most implementation are slowish (probably because of some property of the design, but one that nobody's yet identified). Other than that the main problem with the standard library is that it's based on *copying*. But that's easy to work around, as opposed to how it would have been if it had been the other way around. – Cheers and hth. - Alf Feb 06 '15 at 05:18
  • 1
    The availability of the standard library is a blessing and it should be used in most places. It removes the burden of maintaining fundamental functionality. However, if there is a core piece of your application that is adversely affected by use of the standard library, it's time to roll up your sleeves and write your functions that address the problem. – R Sahu Feb 06 '15 at 05:27
  • Recently I readed an article which talks about this topic [here](http://arne-mertz.de/2015/02/know-your-libraries/), hope you like it. – PaperBirdMaster Feb 06 '15 at 08:09
  • 1
    This has "premature optimization" written all over it. If you work on AAA titles I'm sure you have all the resources and knowledgeable peers who are able to analyse the performance characteristics of widely used (or: to be used) standard library implementations and make a decision based on that. If you don't measure, it becomes an opinion-based decision or worse, one based upon hearsay. Typically in a standard library you'll find that you need only a small % and only a small % of that contributes to runtime performance, so you just replace those with custom implementations as needed. – CodeSmile Feb 06 '15 at 08:46
  • If you have two questions, ask two questions. StackOverflow is free, you don't save money by cramming two questions in one. – MSalters Feb 06 '15 at 09:27

2 Answers2

1
  1. The STL is optimized for performance for general computing. Many applications have specific characteristics which can be leveraged to improve performance (though perhaps only slightly) beyond what's offered by a fully general solution. At the same time, many people do write their own containers and end up with worse performance because they didn't understand the problem well enough, or have bugs that are never found due to limited testing (relative to most STL implementations which receive near infinite testing).

  2. No, there is not generally any detriment to runtime performance simply from including lots of header files.

Apart from your specific questions, if you are developing AAA games, you should look to your peers for guidance on these issues. Any AAA studio will have at least one or two people who are more than qualified to advise you in person at a much greater level of detail.

Finally, while some parts of the STL and C++ standard library do have suboptimal performance for some common use cases (e.g. std::list, iostreams), other parts are generally pretty good (std::vector, std::copy). There's no rule that applies to the entire language...and if there were we'd probably be using another language!

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
0

That is up to the studio. You can write allocators to improve the memory performance based on the topology of your problem, you can create your traits with the exact same reason.

STL is an amazing tool, the problem with its usage is a lot programmers don't know how to, and end up using their own classes for basic things.

e.g, my actual company has a bunch of libraries written in c++ to avoid the STL, after more than 12 years, I found basic bugs in the string implementation, and one co-worker found another in the map.

STL can be blazing fast always you know how to. You should take a look at intel TBB + custom allocators + stl performance. Take a small look at this question Compelling examples of custom C++ allocators?

Community
  • 1
  • 1
Jose Palma
  • 756
  • 6
  • 13