23.11.2007
EA STL
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.
The purpose of this document is to explain the motivation and design of EASTL so that it may help the C++ community better understand the needs of game software development.
This document is not a proposal, though some of EASTL's changes and extensions could form the basis for such discussions. The large majority of EASTL would be useful to any kind of C++ software development.
This document describes an STL implementation (EASTL) developed within Electronic Arts as an alternative to and extension of the STL defined by the C++ standard library. By STL, we mean the container, iterator, and algorithm components of the C++ standard library, hereafter referred to as std STL (with std referring to the std namespace, whereas the S in STL refers to standard C++).
By C++ standard, we mean ISO 14882 (1998) and the 2003 update. The large majority of the design of std STL is excellent and achieves its intended purpose. However, some aspects of it make it hard to use and other aspects prevent it from performing as well as it could.
Among game developers the most fundamental weakness is the std allocator design, and it is this weakness that was the largest contributing factor to the creation of EASTL. Secondarily was the lack of std STL containers designed to be memory-friendly. There are additional reasons that will be discussed below.
13:00 Publié dans Code | Lien permanent | Commentaires (3) | Envoyer cette note
Commentaires
Déjà utilisé sur du vrai code de jeu, et pas qu'une fois. Mais effectivement, elles sont toujours légèrement modifiées et surtout, beaucoup de boulot est fait au niveau des allocateurs.
J'ai vu aussi à droite à gauche des subsets des STL utilisées.
Les STL, quand elles sont arrivées, on subit le même traitement que le C++ lorsqu'il est arrivé : accusées de tous les maux. Dans les deux cas, ce traitement était surtout pour cacher le manque de compréhension et de connaissances du sujet (et malheureusement, ça continue à se voir à droite à gauche, surtout pour le C++).
Les STLs (et boost) forment un outil qu'il est dommage de laisser de côté, même au runtime du jeu. Il fait partie par contre de ces outils puissants avec lequel on peut se tirer dans le pied de manière violente.
Un exemple (vu) est celui qui trouve ça fantastique sur le papier, se met à les utiliser partout tellement c'est pratique. Puis en devenir un farouche adversaire et les virer de partout car, évidemment, un outil n'est jamais universel et son utilisation massive a plombé son code par sa lourdeur.
Mais finalement, des tas de projets qui clament bien haut et bien fort qu'il est idiot de les utiliser en réimplémentent à leur façon de gros morceaux... (très) souvent en moins bien.
EASTL est pour moi une implémentation particulière et non "alternative", plus des ajouts faits. La plus grande valeur ajoutée d'EA, dans cette histoire, c'est ce papier, qui montre les besoins en terme de jeux (particulièrement console), qui sont souvent ignorées de ceux en dehors de cette industrie.
Et je dis bravo, tout en revenant sur la culture du secret dont je parlais ailleurs : beaucoup de boites ont fait ce genre de chose à mon avis (au moins une :) ). Que la boite permette la diffusion du savoir, c'est une autre paire de manche.
Ecrit par : Mokona | 23.11.2007
Un bémol a ton enthousiasme: il s'agit d'un papier, et n'ont d'une version d'EA STL open source LGPL ^_^
Mais en effet, il y a peut être autant de version des STL que de grosses codebases... :-)
Ecrit par : Daz | 23.11.2007
Mon enthousiasme reste entier. Ce n'est qu'un papier, mais un papier qui n'est pas avare de détails.
La même chose chez Gamasutra aurait été : "Nous, à EA, on a trouvé que les allocators de la STL ne convenaient pas, alors on a implémenté quelque chose de mieux." Point. Allez si, en jetant en pâture deux ou trops mots comme "FixedAllocator" "IntrusiveList" histoire de faire bien.
Dans ce papier là, pour peu que l'on soit sensible aux soucis décris, il y a quand même de quoi se mettre sous la dent, c'est expliqué, c'est référencé, argumenté,... Il n'y a pas l'implémentation mais franchement, il y a tout ce qu'il faut pour s'inspirer de leur boulot.
Après, qu'ils n'aient pas eu envie de filer le source, c'est un autre soucis, mais ça ne me gêne pas.
Ecrit par : Mokona | 23.11.2007
Écrire un commentaire