For what most games do - which in terms of non-graphical computation and data management, isn't generally very much - STL is going to be fine. And if you write something STL_like, in terms of providing general containers, you probably won't get much in the way of improvement, at least if you design for the basic capabilities.
But keep in mind that in the modern world, everyone's got a dual core 2Ghz processor or better, at least if they want to play games. There was a time people wrote games for machines 50 times slower, and you can believe that a great deal of squeezing went on to get speed any way they could. You used fixed arrays because that was the only thing fast enough. You hand optimized things like hash functions. You unrolled loops and you used assembler. Some of that tradition still survives.
I'd say this: use things like STL to get started. If you find you're writing something so ambitious that the costs of STL are in the way, then you can fade the use of STL out in the critical areas, and go back to the old methods.
The Myth About STL
if i'm working on my 286 just playing around i use every speed trick i know, but for the most part, i use what works now and if it too slow i either find something that fixes it or figure out some other way to achieve what i want
Quote:Original post by obhi
Can anybody clear a myth that surrounds me about STL. Is STL fast enough for games ??
I know I might get kicked for asking this question given the debate that surrounds the usage of STL. But I have looked around and into a lot of open source engines. Most dont use STL. Can anybody explain that ??
depends. for what you are likely to do, yes
for consoles, and platforms with limited memory, its nice to have some fixed size containers which dont call allocators, fixed element size containers (which also dont hit constructors), and other non-resizing containers.
such things arent found in the STL.
it comes down to that, in certain situations, you can make decisions based on the data you have, and the memory budgets you need to fit within and the resulting solution will be better(sic) than using a generic container.
this also only applies to runtime situations. for tools, we use everything we can lay our hands on.
but back to the original point, if your a hobby programmer, or writing smallish games, and not trying to eek every last cycle out of the hardware (and at a guess, your not) and would rather spend the time writing code and using good, tested, fast containers then use STL, and dont feel bad about it.
Contrary to popular nonsense, basic operations on vectors don't have to be slower than equivalent operations on arrays/pointers, see http://www.xs4all.nl/~weegen/eelis/vector-speed.cpp.
Newbies don't want to use SC++L for so many reasons: Because the pros roll their own, because they want to learn as much as possible, because they don't know how it's working internally, because misusage produces strange error messages, because good online help is hard to come by.
Pros roll their own after they've been through all this.
Alas I know of some pros who never really used SC++L... I guess they are just too busy writing code to really learn C++. [smile]
Pros roll their own after they've been through all this.
Alas I know of some pros who never really used SC++L... I guess they are just too busy writing code to really learn C++. [smile]
Thanks for the reply's. You see I asked this question because I am using my own containers that I implemented a long time back. Most of them basically cuts down to what SC++L has inbuilt, specializing in certain areas. Memory management for example. But when I started posting here I noticed people talk about SC++L a lot. And since I neglected SC++L from the day I was learning C++, I had to know what makes it tick in the gaming world. Or does it really carry its fame that I noticed here to the commercial engines.
And
Thats for sure! But they are open source and available for study.
And
Quote:
Crystal Space is an ancient piece of shit, and there's some evidence that Irrlicht was written by people who didn't know what they were doing at all.
Thats for sure! But they are open source and available for study.
Quote:Original post by loufoque
Contrary to popular nonsense, basic operations on vectors don't have to be slower than equivalent operations on arrays/pointers, see http://www.xs4all.nl/~weegen/eelis/vector-speed.cpp.
You left out the fact that vectors have to be created and destroyed. The memory for the storage of elements has to come from somewhere, and if you add to the vector often enough, it's going to mean more trips to that special somewhere. Ultimately, these are heap operations. Heap allocations are searches; they are not free. An array creation takes 0 time (but see below) and, as it can't grow, it can't cost more time at a later point.
At heart,
class Foo {
std::vector<MyData> list;
and
class Foo {
MyData list[256];
may perform (and should perform) identically when indexing into list[], but they are not identical as regards what it costs Foo to be created, list[] to be added to, and Foo to be destroyed. Of course, vector has all sorts of advantages, starting with the fact that you don't have to know in advance how many elements you need. It's there to free you from the substantial restrictions of arrays. But such freedom isn't free.
All bets are off, of course, if MyData is a class with a slow, complex default constructor, in which case the array case is going to expensively construct 256 objects, which is annoying if you only needed 3. The vector init doesn't have to create any. But if you are worried about performance to this degree, you are already looking at these issues and know when array is not going to win. (caveat: the same argument can affect the vector case when a class has an extremely expensive copy constructor. Array elements can be built in place, they don't have to be loaded by a copy operator.)
STL is great for many things. Some people will never need more. But anyone who codes long enough and pushes machine limits as part of his work, is always going to find a case, sooner or later, where the latest panacea, be it STL or anything else, has some unacceptable cost. If that day comes, it is important to know what the alternatives are and how they behave.
At my company we use both STL and Boost extensively in our console game.
Pretty generally, if just use some common sense and don't pack a ton of this into very tight loops, you'll be all set.
We HAVE encounter some bottle necks with STL, but nothing that wasn't able to be remedied with some careful evaluation.
Pretty generally, if just use some common sense and don't pack a ton of this into very tight loops, you'll be all set.
We HAVE encounter some bottle necks with STL, but nothing that wasn't able to be remedied with some careful evaluation.
Quote:Original post by obhi
AndQuote:
Crystal Space is an ancient piece of shit, and there's some evidence that Irrlicht was written by people who didn't know what they were doing at all.
Thats for sure! But they are open source and available for study.
Here's you situation made clearer:
"Don't eat this mushroom, it's poisonous!"
"But it's free and right there on the floor!"
"..."
The biggest myth about STL is that it's to slow for serious development.
Another huge problem is people being absolutely obsessive about "slow" and making dubious micro-optimizations without looking at algorithmic changes or even bothering to measure performance and understand what exactly it is that's slow. Or in some cases, even defining what "slow" is.
Yet another problem is people thinking that the demands of a AAA title that is pushing the technology envelope are somehow relevant to thier small-medium title that will run just fine on 3 year old hardware without going to heroic optimization efforts.
Another huge problem is people being absolutely obsessive about "slow" and making dubious micro-optimizations without looking at algorithmic changes or even bothering to measure performance and understand what exactly it is that's slow. Or in some cases, even defining what "slow" is.
Yet another problem is people thinking that the demands of a AAA title that is pushing the technology envelope are somehow relevant to thier small-medium title that will run just fine on 3 year old hardware without going to heroic optimization efforts.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement