EA open sources their internal version of STL
1–10 of 37 posts
Re: EA open sources their internal version of STL
#2Source: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...
Differences between std STL and EASTL
First, EASTL provides a set of containers, iterators, and algorithms that are identical in interface and behavior to std STL versions with one exception: allocators. EASTL has a different allocator specification which is simpler, more efficient, more flexible, and easier to use than std::allocator. Both std::allocator and eastl::allocator are described below. EASTL follows the defect reports and TR1 as well. EASTL additionally provides and uses some of the TR1 functionality as well, including most significantly the smart pointers, type traits, and hashing containers.
Second, EASTL provides extension functionality to the above containers, iterators, and algorithms. An example of this is the push_back(void), set_capacity(size), and validate() functions added to eastl::vector. The majority of these extensions are driven by the need for higher performance (push_back(void)), higher clarity (set_capacity), or higher debuggability (validate()). There are about 30 such extensions to the various entities in the library. These are described in detail below.
Third, EASTL provides additional containers and algorithms that don't correspond to std STL. These include intrusive_list, vector_map, fixed_hash_set, slist, ring_buffer, radix_sort, has_trivial_relocate, and others. These are described in detail below.
There are additional differences not related to the functional specification. They include a programming philosophy that emphasizes readability, consistency, and optimal performance on limited hardware.
Re: EA open sources their internal version of STL
#3http://news.ycombinator.com/item?id=1798215 - barrybe set up that github.
Here are first rough benchmarks: http://msinilo.pl/blog/?p=668
Re: EA open sources their internal version of STL
#4This is why game companies use C++. They've already reimplemented it internally and don't ever want to do that again.
Re: EA open sources their internal version of STL
#5This is why game companies use C++. They've already reimplemented it internally and don't ever want to do that again.
I imagine most STL classes still don't fit game programming paradigms. My very first experience with this was using vectors to store vertices as an intermediary before sticking them into a vertex buffer. Granted, my math was awful, but the memory overhead was absurd. I constantly find myself over using STL in my programs because of how easy it is, then redoing it to use standard C/C++ arrays, linked lists, etc. for efficiency.
Ranting aside, I'm most curious to look at any optimizations they've made.
Re: EA open sources their internal version of STL
#6This is why game companies use C++. They've already reimplemented it internally and don't ever want to do that again.
I imagine most STL classes still don't fit game programming paradigms. My very first experience with this was using vectors to store vertices as an intermediary before sticking them into a vertex buffer. Granted, my math was awful, but the memory overhead was absurd. I constantly find myself over using STL in my programs because of how easy it is, then redoing it to use standard C/C++ arrays, linked lists, etc. for e…
Any sane implementation of std::vector is probably going to have three pointers of overhead, and might allocate twice as much memory as required in the worst case when you push a bunch of objects into it. That doesn't seem totally absurd to me - was yours much worse, or am I just being more tolerant of it?
Re: EA open sources their internal version of STL
#7E. A. STL. It's in the game.
But don't say it like that, it's against the license ;p
Re: EA open sources their internal version of STL
#8This is why game companies use C++. They've already reimplemented it internally and don't ever want to do that again.
A surprisingly large number of companies have their own STL implementations from Investment Banks to Telecoms companies. Often because they're doing funky things (often related to memory allocation) which would be outright impossible to do in languages like Java or C#.
Re: EA open sources their internal version of STL
#9This is why game companies use C++. They've already reimplemented it internally and don't ever want to do that again.
A surprisingly large number of companies have their own STL implementations from Investment Banks to Telecoms companies. Often because they're doing funky things (often related to memory allocation) which would be outright impossible to do in languages like Java or C#.
I have never seen anyone mix their custom memory manager with STL. Also, who said anything about Java or C#?
Re: EA open sources their internal version of STL
#10Earlier quoted context omitted.
I imagine most STL classes still don't fit game programming paradigms. My very first experience with this was using vectors to store vertices as an intermediary before sticking them into a vertex buffer. Granted, my math was awful, but the memory overhead was absurd. I constantly find myself over using STL in my programs because of how easy it is, then redoing it to use standard C/C++ arrays, linked lists, etc. for e…
Any sane implementation of std::vector is probably going to have three pointers of overhead, and might allocate twice as much memory as required in the worst case when you push a bunch of objects into it. That doesn't seem totally absurd to me - was yours much worse, or am I just being more tolerant of it?
You're being more tolerant. When you're building a high performance game engine for fixed target hardware, the last thing you want is to be doubling up the size of your arrays.