I heard that the STL is too slow for use in a high-performance game. I've been told that if you want to use the same coding techniques as a AAA game, you have to make custom classes for all your linked lists, trees, etc., rather than just using LinkedList<MyClass> (or whatever the STL syntax is).
Is this true?
My game will be so simple that the performance will not really matter. I'm doing this for the programming experience.
C++ - do you use STL in your game?
Claims that STL is "too slow" are utter nonsense. Especially std::vector is identical in performance to a "raw dynamic array". You will have a REALLY hard time writing faster containers than the ones in good STL implementations. Now there might be the case that your data has a special structure that you can abuse, in that case you can think about rolling your own.
I use the STL in my (2D RPG) game. The only performance critical part of my code is streaming the map from file around the player; I didn't find the standard library to be any slowdown, at least, not more than my own code was slowing things down. The real critical issue of speed that I had come up against was all the new-ing and delete-ing calls, so I found the greatest optimization for me was to re-use the dynamic memory in the really performance intensive areas. But everywhere else I don't worry about either dynamic memory or the STL.
Another issue was from me using boost::shared_ptr() stupidly... In general, the greatest slowdowns I encounter are from me mis-using libraries, not from the libraries themselves being slow. For example, if you are push_back()ing 400 elements in a vector without first calling reserve(), you are doing it wrong.
The standard library is better optimized than I can do on my own. My occasional poor usage of the standard library is what causes slowdowns.
Just use the library intelligently, and don't prematurely optimize, and you'll be fine. When you do encounter a slowdown, profile, find out where the bottleneck is, and optimize that area. If, in that situation, you find a STL class to be the bottleneck (unlikely, but possible), then in that one area of code roll something faster, but continue to use the standard library everywhere else.
([size=2]FWIW, I'm a hobbyist trying to go independant working on 2D games, not a industry veteran working on the latest triple-A pixel-fest FPS)
Another issue was from me using boost::shared_ptr() stupidly... In general, the greatest slowdowns I encounter are from me mis-using libraries, not from the libraries themselves being slow. For example, if you are push_back()ing 400 elements in a vector without first calling reserve(), you are doing it wrong.
The standard library is better optimized than I can do on my own. My occasional poor usage of the standard library is what causes slowdowns.
Just use the library intelligently, and don't prematurely optimize, and you'll be fine. When you do encounter a slowdown, profile, find out where the bottleneck is, and optimize that area. If, in that situation, you find a STL class to be the bottleneck (unlikely, but possible), then in that one area of code roll something faster, but continue to use the standard library everywhere else.
([size=2]FWIW, I'm a hobbyist trying to go independant working on 2D games, not a industry veteran working on the latest triple-A pixel-fest FPS)
Just to get a nit-pick out of the way first, the library you're talking about is not the STL, it's the C++ Standard Library -- although the former term is so often used as to make them almost interchangeable, and you'll likely never run into a situation where it leads to confusion.
As to your actual question, my recommendation would be that implementing your own containers and algorithms can be a great learning experience, and one that every programmer would benefit from tackling at some point, but that you should then go right back to using the well-tested and very capable versions provided by the standard library in your actual code.
Yes, it is true that the standard library (or parts thereof) are not always used in professional development. This is due to a number of reasons, and some of the valid ones include lack of a good implementation (or any implementation) for a particular target platform and performance concerns. Some of the invalid ones include NIH syndrome, inexperienced programmers, or acting on rumoured poor performance without actually testing the suitability for their own usage. Writing and using your own versions when those good reasons don't apply to you likely won't provide a particularly valuable experience however.
Some other reasons I recommend using the standard library:
-It's standard, and therefore (if used appropriately) clearly communicates the intentions and usage of your code to other programmers. Other programmers will be experienced with these containers and be able to follow your code without having to examine the implementations of your containers or algorithms.
-The performance concerns are often over-stated, and unless you know they actually apply to your situation and have the experience to write a good alternative you probably won't get any benefit. Using the standard library extensively may also allow you to get a good grip on what limitations do actually exist.
-Some studios do use the standard library, and it's also valuable in non-games programming.
-Some studios will improve the standard library's performance (by providing custom allocators, etc.) rather than rolling their own version, in which case your experience would remain relevant.
-Making use of the standard library will more easily allow you to finish your own bug-free and acceptably performant projects in a reasonably amount of time -- would you prefer a portfolio with a number of polished and bug-free games, or with a lesser number of potentially buggy games that use your own implementations?
-Some studios will use their own implementations, such as EASTL for example. Given these libraries are quite often intended as replacements for the standard library, experience with using the standard library will give you an excellent starting point for being able to quickly learn the proper usage of these alternatives if necessary.
TL;DR:
Write your own versions as an educational experience, but use the standard library in your actual projects.
Hope that's helpful! 
Author
Thanks, guys. I got some experience writing my own linked lists and trees in the past, so I think I'm going to go with the collections provided by the C++ standard library.
One reason AAA games may not use the C++ Standard Library is because of poor compiler support for certain standard language features, such as exceptions or templates. Some compilers for some consoles don't support these things too well, and so an alternate will be developed that doesn't use (or avoids using too much) exceptions or templates to work around the compiler's lacking implementation.
Another reason might be because the developers are targeting a specific operating system, and that operating system has some custom functions that allow the developers do something very specific (like memory-mapping files, for example). The developers may rewrite parts of the C++ Standard Library to take advantage of such specific functionality that's not exposed in the C++ Standard Library.
I'm just giving a couple of examples for when one might be justified in rewriting parts of the C++ Standard Library. If you're rewriting it (or parts of it), you need to have a very specific goal in mind and a very specific problem you're solving/working around. A naive rewrite is worse than stupid (unless doing it solely for educational purposes).
I haven't worked on a AAA game, but I've worked on some industrial-level software that sells for several thousands of dollars, and we use the C++ Standard Library (I haven't dug into the speed critical parts, but I think those are mostly done in assembly or SSE instructions where data structures aren't the bottleneck and the C++ Standard Library doesn't have algorithms for what we're doing). Use it.
I think jbadams summed up my opinions and views very well though.
Another reason might be because the developers are targeting a specific operating system, and that operating system has some custom functions that allow the developers do something very specific (like memory-mapping files, for example). The developers may rewrite parts of the C++ Standard Library to take advantage of such specific functionality that's not exposed in the C++ Standard Library.
I'm just giving a couple of examples for when one might be justified in rewriting parts of the C++ Standard Library. If you're rewriting it (or parts of it), you need to have a very specific goal in mind and a very specific problem you're solving/working around. A naive rewrite is worse than stupid (unless doing it solely for educational purposes).
I haven't worked on a AAA game, but I've worked on some industrial-level software that sells for several thousands of dollars, and we use the C++ Standard Library (I haven't dug into the speed critical parts, but I think those are mostly done in assembly or SSE instructions where data structures aren't the bottleneck and the C++ Standard Library doesn't have algorithms for what we're doing). Use it.
I think jbadams summed up my opinions and views very well though.
The big problem of stl is such that his implementation on different compilers are not the same, but this don't must stop you to using him
Boost containers are alternative of stl
You aways can typedef the container
And if you have performance problem you aways can change typedef with your own container
The only requirement is such that your container must have all methods of stl container equivalent
Boost containers are alternative of stl
You aways can typedef the container
typedef std::vector<Unit> UnitArray;
And if you have performance problem you aways can change typedef with your own container
typedef MyVector<Unit> UnitArray;
The only requirement is such that your container must have all methods of stl container equivalent
I agree with jbadams post with a few additions.
Two things to keep in mind.
First, there's a few people out there who aren't aware of the iterator debugging in visual studio's implementation of the STL (standard template library) containers. This causes a major slowdown in debug builds, and release code are often tens of times faster without it! Declare NDEBUG, or some _NO_ITERATOR_DEBUG (I think it was) to get rid of it. You can find the details on msdn if need be. It's a good safety net though that can really catch nasty bugs.
Second of all: all STL and standard library features are generalized to allow for a one-fits-all solution. This is generally a good thing, and they've implemented it in such a great way so that you can even assign your own memory allocators to avoid that potential slowdown too, which was mentioned before. Having them take memory from a pre-allocated pool greatly improves performance for the linked containers.
..But, generalized is always generalized, which means that you can't optimize it for your particular case and may run a bit slower because of it. You'd still have to be a damn nifty coder to make it better and as stable as the STD library.
Saying that, STL containers is my first choice, always. Most reasons stated by jbadams already.
Two things to keep in mind.
First, there's a few people out there who aren't aware of the iterator debugging in visual studio's implementation of the STL (standard template library) containers. This causes a major slowdown in debug builds, and release code are often tens of times faster without it! Declare NDEBUG, or some _NO_ITERATOR_DEBUG (I think it was) to get rid of it. You can find the details on msdn if need be. It's a good safety net though that can really catch nasty bugs.
Second of all: all STL and standard library features are generalized to allow for a one-fits-all solution. This is generally a good thing, and they've implemented it in such a great way so that you can even assign your own memory allocators to avoid that potential slowdown too, which was mentioned before. Having them take memory from a pre-allocated pool greatly improves performance for the linked containers.
..But, generalized is always generalized, which means that you can't optimize it for your particular case and may run a bit slower because of it. You'd still have to be a damn nifty coder to make it better and as stable as the STD library.
Saying that, STL containers is my first choice, always. Most reasons stated by jbadams already.
I heard that the STL is too slow for use in a high-performance game.
[/quote]
Any performance issues that AAA companies find with the Standard C++ Library is that it's general nature doesn't allow them to do certain things. For instance, there isn't a way to tell std::vector<> to use a given piece of memory easily. The "allocator" parameter for standard library templates are a little underbaked and often don't give enough control to the client programmer.
Thus, the problems are of a design nature, not the actual implementation. The implementation of the standard containers tends to be very high quality. Most programmers are not going to beat the performance of classes like std::vector if they stick to the interface it outlines. In fact, many underexperienced programmers are likely to produce code that is algorithmically poorer, and thus will suffer heavily in real use.
I've been told that if you want to use the same coding techniques as a AAA game, you have to make custom classes...
[/quote]
It makes no sense to apply the "coding techniques" of a massive, professional team to your small personal projects.
... your linked lists, trees, etc., rather than just using LinkedList<MyClass> (or whatever the STL syntax is).
[/quote]
If you're worried about performance, you should strongly consider not using linked lists at all. They are almost always going to be slower than dynamic arrays on modern machines with real data.
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][background=rgb(250, 251, 252)]I'm doing this for the programming experience.[/background]
[/font]
[/quote]
I believe there is great value in implementing the standard containers yourself, as a learning exercise, in particular if you have a reliable source to get some feedback from. However, I would not recommend using such an implementation for a real project.
If you're worried about performance, you should strongly consider not using linked lists at all. They are almost always going to be slower than dynamic arrays on modern machines with real data.
Well, that would depend on how it is used. If you need to insert or remove items somewhere in the middle instead of just at the end (vector) or at the beginning or the end (deque) a linked list it practically guaranteed to be faster. Use the proper container for a given algorithm, taking into account the algorithmic performance (in this case O(1) vs O(n) insertion).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
