Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

23/11/2007

EA STL

Aaahhh, les Standard Template Library - ou STL pour les intimes! Des heures et des heures de discutions, disputes, voir franches bagarres autour des fonctionnalités qu'elles apportent et de leurs problèmes dans le cadre du jeu vidéo...
 
 
Je ne vais pas ici détailler la teneur du débat, alors allons à la conclusion: en théorie, les STL sont de fantastiques outils de production qu'il faut absolument connaitre... sauf dans le code du jeu. 
 
 
En pratique, dans a peu près toutes les codebases que j'ai pu voir, les STL restent réservés au code des outils ou des éditeur. En général, au mieux, une implémentation alternative fourni un sous ensemble des fonctionnalités des STL pour le code du jeu.
 
 
Au pire, vous êtes livrés à vous même ^_^.
 
 
Du coup, il existe des dizaines d'implémentations alternatives des STL, comme celle d'EA, que Paul Pedriana détaille dans un excellent article de fond.
 
 
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.

 
 
[ EASTL
 
 

13:00 Publié dans Code | Lien permanent | Commentaires (3)

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.

Écrit 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... :-)

Écrit 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.

Écrit par : Mokona | 23/11/2007

Les commentaires sont fermés.