Jump to content
  • Advertisement
Sign in to follow this  
Muhammad Haggag

Electronic Arts Standard Template Library

This topic is 4217 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This paper came up on programming.reddit today: Electronic Arts Standard Template Library. Abstract:
Gaming platforms and game designs place requirements on game software which differ from requirements of other platforms. Most significantly, game software requires large amounts of memory but has a limited amount to work with. Gaming software is also faced with other limitations such as weaker processor caches, weaker CPUs, and non-default memory alignment requirements. A result of this is that game software needs to be careful with its use of memory and the CPU. The C++ standard library's containers, iterators, and algorithms are potentially useful for a variety of game programming needs. However, weaknesses and omissions of the standard library prevent it from being ideal for high performance game software. Foremost among these weaknesses is the allocator model. An extended and partially redesigned replacement (EASTL) for the C++ standard library was implemented at Electronic Arts in order to resolve these weaknesses in a portable and consistent way. This paper describes game software development issues, perceived weaknesses of the current C++ standard, and the design of EASTL as a partial solution for these weaknesses.
It's a very interesting read.

Share this post


Link to post
Share on other sites
Advertisement
I caught that too.

I think some of the observations within were based on a particular implementation of the STL, though e.g. the stuff about void-pointers in node-based containers.

But it is an interesting discussion, certainly.

Edd

Share this post


Link to post
Share on other sites
Quote:
Original post by the_edd
I think some of the observations within were based on a particular implementation of the STL, though e.g. the stuff about void-pointers in node-based containers.

Well, that's the point--they wanted unified behavior across different implementations.

Share this post


Link to post
Share on other sites
Well, they can't demand something like that, IMO, at least not in this way.

Sticking to the standard does give unified behaviour. That's the whole point of the standard. They're talking about implementation details, which the standard does not define and nor should it; it's up to the library implementer to decide what's the best way to do something for a particular system.

If the implementer of the library they're using isn't doing a very good job, they should take it up with them and not impose rules on every implementer. I realise that's not what they're doing.

A lot of their suggestions and comments are rational and well-justified and I agree with a lot of what is said.

But I think in a few of the situations highlighted, the issue seems to be with a particular implementation of the standard library that they're using.

Edd

Share this post


Link to post
Share on other sites
I understand what you mean--you can't specify, in the standard, that implementations should provide the programmer a proper view of the data with a debugger. That's outside the scope of a language standard. That's why they came up with their own (cross-platform) implementation that guarantees it.

Share this post


Link to post
Share on other sites
Very interesting read, thanks for posting it.

The document sums up perfectly why we have banned the use of the STL/standard library in all of our corporate projects, and replaced it by our own implementation. On the other hand, it gives some very interesting ideas about optimizing and extending this in-house implementation.

Quote:

Sticking to the standard does give unified behaviour. That's the whole point of the standard.

While this is true, it is also its greatest weakness. As a programmer, I expect a certain amount of functionality and ease of use from a library. This is specifically true for areas such as efficient debugging, efficient and flexible performance and storage characteristics, low memory footprint, highly controllable multithreaded behaviour, cross-DLL boundary safety, etc.

These are all implementation details, and thus ignored by the current standard. Yet, they are immensely important.

Share this post


Link to post
Share on other sites
Quote:
While this is true, it is also its greatest weakness. As a programmer, I expect a certain amount of functionality and ease of use from a library. This is specifically true for areas such as efficient debugging, efficient and flexible performance and storage characteristics, low memory footprint, highly controllable multi-threaded behaviour, cross-DLL boundary safety, etc.
These are all implementation details, and thus ignored by the current standard. Yet, they are immensely important.


Well the standard doesn't mention DLLs or multithreading (yet) at all. It can't mention DLLs because they're tied to a particular platform. One could argue that something related to shared libraries could be added but the differences in the way shared libraries are handled between platforms is so broad that it would be pointless trying to extract vague and tenuous commonality for potential standardisation.

Doing any kind of multi-threading in C++ is dangerous unless you know your compiler and platform inside out (which you may, of course) because the standard behaviour is defined in terms of a single threaded virtual machine (for now) and the guarantees for different platform/compiler combinations vary greatly in the wild.

I guess I'm just saying it's unfair to criticise a platform-neutral standard for failing to standardise something platform specific. I'm not entirely sure that's what you were doing, though :)

If there are other issues with the library, it's often the implementation that needs to be improved and not the specification. For instance, a large number of the suggestions made in the article are only improvements over a particular implementation.

I certainly agree that debug-ability is generally quite bad, though it doesn't need to be. The library being developed for the Open Watcom compiler is very readable, for example.

One of the things that I really agree with is that the whole allocator concept, as it stands currently, is just severely flawed for a number of reasons. I really hope that gets sorted in the standard some time soon.

Edd

Share this post


Link to post
Share on other sites
It doesn't really matter what they do.

Standard STL is important for portability and re-use. In a large corporation working with proprietary confidential code, external code re-use isn't a big deal, and their code will not be published as general purpose.

So the only benefit of remaining standard compliant is void.

That said, STL is generic. Game development on the other hand has always looked for highly tuned solutions. The mere adoption of STL seems like big step to me.

But EA is interested into one thing only - getting things done. If it means breaking the standard, or abandoning it completely, they will. It's purely practical - if it gets their job done faster/better/more reliably/more conveniently, why not.

This is interesting read, and it is clearly stated as EA STL. It's something they use for themselves, but during cursory read, I didn't see any implication that they want to replace STL standard.

Share this post


Link to post
Share on other sites
It works for them, obviously. But they're also a large enough company to have staff that can be dedicated to development and maintainance. Most of us, unfortunately, don't have that luxury -- most non-publisher entities don't either.

Good for them though, interesting read.

Share this post


Link to post
Share on other sites
The question is, are they willing to release it under a permissive license? Sadly, I suspect they're not, but a man can dream.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!