Discussion :

[screetch]

Nous sommes donc bien d'accord que c'est, encore une fois, le genre de pratique à ranger dans la catégorie des "si on ne peut vraiment pas faire autrement"

La réaction de Goten est donc, a priori du moins, tout à fait justifiée

Je ne conteste pas que la reaction de Goten est justifiée (surtout dans ce cas) mais nous nous sommes rendus compte que l'utilisation de la S(t)L pesait pour plus de 3 megs dans notre executable. Travaillant sur des machines qui ne sont pas des PC (playstation3 et XBox), c'est quand meme 3 megs que l'on ne reverra jamais (sur les 256 dont on dispose). C'est un peu gravos.

Je pense aussi que la SL n'est pas super top niveau en fait. Disons que si un comité s'était penché sur la question durant quelques années on en serait pas la.

Mais on parle bien de plusieurs specialistes du C++ pendant plusieurs années, pas d'un geek dans le sous-sol de ses parents

[sleepless]

Hey ! Je n'ai jamais dit que j'espérais faire mieux que la STL dans le cas général, mais seulement dans un cas bien précis.

D'autre part, les geeks de mon age ont un sous-sol bien à eux

[Goten]

Je ne conteste pas que la reaction de Goten est justifiée (surtout dans ce cas) mais nous nous sommes rendus compte que l'utilisation de la S(t)L pesait pour plus de 3 megs dans notre executable. Travaillant sur des machines qui ne sont pas des PC (playstation3 et XBox), c'est quand meme 3 megs que l'on ne reverra jamais (sur les 256 dont on dispose). C'est un peu gravos.

Je pense aussi que la SL n'est pas super top niveau en fait. Disons que si un comité s'était penché sur la question durant quelques années on en serait pas la.

Mais on parle bien de plusieurs specialistes du C++ pendant plusieurs années, pas d'un geek dans le sous-sol de ses parents

C'est quoi comme compilo? Parce que le mythe du code bloat du C++ qu'aime tant nous ressortir les puristes du C perso je l'ai même pas connu! (bon ok j'exagère).
Je demande ça pas parce que je te crois pas, mais au contraire parce que ça m'intéresse car il me semble déjà avoir entendu que les compilo pour les consoles (PS3 il me semble) étaient vraiment pas top top niveau C++. Donc ça mérite confirmation .

Quant à dire que la SL est pas super top, si tu parles d'un point de vue perf / bloat, ça veut pas dire grand chose, ça varie tellement d'un implémentation à une autre. (celle d'apache par exemple est très bien, celle de VS est plus... étonnante, et celle de gcc est ... je préfère pas en parler). Maintenant si tu parles au niveau design de la SL alors ouai, y'a quelques classes qui seraient à revoir (std::string etc ..)

Méfie toi des geek dans les sous sol : p


Oh et quant à ma remarque qui a été fait couler tant d'encre (ou plutôt user tant de bande passante :p) c'était bien évidemment pas lâcher comme ça innocemment (si j'ose dire presque trollesquement) mais bien orienté pour le PO.

[koala01]

Je me laisse facilement convaincre par Joel au sujet de l'amitié : c'est plus simple à maintenir sans, et on peut espérer que le compilateur va optimiser. Je trouve ça juste frustrant que ça ne soit pas écrit explicitement dans le code. Il me semble même avoir lu que l'utilisation de "inline" était une simple indication qui n'obligeait en rien le compilateur à inliner quoi que ce soit (je me trompe ?).

Effectivement, le compilateur peut décider de ne pas inliner une fonction s'il est dans l'impossibilité de le faire (ex: il sera incapable d'inliner une fonction récursive ) ou si le nombre d'instructions est supérieur à la limite admise (cetains compilateurs permettent de modifier cette limite )

Sinon, les "vrais compilateurs", c'est lesquels ?

En gros, on peut estimer que tout compilateur postérieur (ou égal) à 2005 peut être considéré comme un "vrai" compilateur.

Si tu te pose la question de savoir pourquoi je parle de l'année 2005, c'est simplement parce que:

• Ce n'est qu'avecTR1 (sorti en 2003) que pas mal de problèmes ont été réglés (entre autres au niveau de la gestion des template et des espaces de noms), sans oublier tous les ajouts qu'il a apportés
• c'est à peu près à cette date que microsoft a complètement changé son fusil d'épaule en ce qui concerne le respect des différentes normes (en fait, c'était un peu plus tôt, mais il a bien fallu le temps que cela se traduise dans les différents outils )

Par contre, je vais essayer de résister un peu en ce qui concerne la STL. Je m'attendais à ce qu'on m'objecte que le gain de performance ne valait pas le coup par rapport au temps passé à réinventer la roue (et à la débugger).

Attention, il y a aussi de cela

Mais certainement pas à ce qu'on me présente l'exercice comme un challenge de haute volée (et donc hors de mes capacités).

Attention, on ne vise pas tes capacités de manière particulière, on vise les capacités de n'importe quel programmeur en général, quel que soit sont niveau de compétences...

Le fait est que même avec un niveau de compétences important, le temps passé sur l'exercice sera important.

Comme ce serait cruellement manquer de modestie de parler de moi, je peux t'assurer que je tiens personnellement Emmanuel pour quelqu'un de particulièrement compétant, pourtant, sa réponse ne laisse aucune place au doute: il y arrivera surement, mais il lui faudra le temps

Comment une lib aussi générale et riche en fonctionnalité que la STL peut elle performer mieux que des conteneurs minimalistes et dédiés à une utilisation bien précise ?

Essentiellement parce que le nombre de gens qui posent les yeux dessus est important:

L'implémentation de la STL est toujours le travail d'une équipe, et donc de "compétences croisées". Ne dit on pas qu'il y a toujours plus dans deux têtes que dans une et dans dix, cent ou mille alors

Il faut être conscient que l'on a beau être particulièrement compétent (c'est peut être ton cas ), il y a toujours des domaines que l'on maitrise moins bien, et que c'est parfaitement normal .

Le fait de travailler en équipe permet, tout simplement, de croiser les domaines de compétences et donc d'avoir une chance accrue de voir l'ensemble des domaines profiter d'un niveau de compétence important, alors que c'est purement impossible lorsque tu travailles seul, que ce soit dans ton garage ou ton salon

Je vais être têtu, et je promets de revenir d'ici quelques semaines avec un benchmark pour comparer les deux dans le contexte de mon appli.

Voilà une excellente idée

Probablement une humiliation publique en perspective,

On n'a pas vraiment l'habitude d'humilier publiquement les gens ici

Par contre, si ton bench est effectué correctement (j'ai appris à n'accorder qu'une confiance limitée en un bench que je n'ai pas moi même truqué ), tu pourra soit profiter de point de vue différents (et donc de nouvelles voies de réflexion ) soit... faire profiter les autres de tes "idées de génie"

mais si c'est le cas, au moins ça m'aura vacciné contre l'excès de confiance en moi

Tout de suite les grands mots

(et ça m'aura fait progresser avec les templates).

Ce qui sera déjà pas si mal, en soit

Et pour l'implémentation de mon conteneur "dynamique" (si si, un peu!) non, je ne fait pas une allocation à chaque ajout d'un nouvel élément, le résultat serai catastrophique niveau performance. J'utilise une méthode "SetSize()" pour définir la capacité du tableau, et il revient à l'appelant de ne pas changer la taille à tout bout de champ. Concrètement, il est exceptionnel que la taille change en court de route (et ça n'arrive jamais dans la boucle principale).

En fait, quand j'écrivais "tu te retrouvera face à la nécessité d'augmenter la taille", je voulais, bien évidemment, parler de l'implémentation des mécanismes internes à ta classe

La gestion de la taille de ton tableau doit, effectivement, être du seul ressort du conteneur

Hey ! Je n'ai jamais dit que j'espérais faire mieux que la STL dans le cas général, mais seulement dans un cas bien précis.

et on a juste dit que ce ne sera pas évident d'y arriver seul.

Tu y arrivera sans doute, mais le temps que tu aura passé à y arriver (et à acquérir les compétences nécessaires, s'il t'en manque) mérite clairement d'être mis en balance avec le gain que tu peux espérer grâce à l'exercice

D'autre part, les geeks de mon age ont un sous-sol bien à eux

et sans doute un bureau confortable, dans la même pièce que la TV

[Joel F]

Pour avoir développer pendant 2 ans sur PS3 et Blade Q22, le principale probleme est que le libstd de ces plateforems fait genre entre 1.2M et 4M ...
Sachant que sur PS3, les SPE du processeur Cell ont 256K de scratchpad, c'ets un peu la loose. Personnelement, ca ne m'empecher pas d'utiliser la STL, suffisait de jamais inclure des trucs genre <{i,o,f,s}stream>. Itou avec Boost, tt passe sauf les trucs avec des .a garrgantuesques.

[screetch]

sur PS3 le compilateur (nous) refuse de merger les méthodes similaires, tels que les vector<A*> et les vector<B*>, bien que le code généré soit identique.

[guillaume07]

C'est quoi comme compilo? Parce que le mythe du code bloat du C++ qu'aime tant nous ressortir les puristes du C perso je l'ai même pas connu! (bon ok j'exagère).
Je demande ça pas parce que je te crois pas, mais au contraire parce que ça m'intéresse car il me semble déjà avoir entendu que les compilo pour les consoles (PS3 il me semble) étaient vraiment pas top top niveau C++. Donc ça mérite confirmation .

Quant à dire que la SL est pas super top, si tu parles d'un point de vue perf / bloat, ça veut pas dire grand chose, ça varie tellement d'un implémentation à une autre. (celle d'apache par exemple est très bien, celle de VS est plus... étonnante, et celle de gcc est ... je préfère pas en parler). Maintenant si tu parles au niveau design de la SL alors ouai, y'a quelques classes qui seraient à revoir (std::string etc ..)

Méfie toi des geek dans les sous sol : p


Oh et quant à ma remarque qui a été fait couler tant d'encre (ou plutôt user tant de bande passante :p) c'était bien évidemment pas lâcher comme ça innocemment (si j'ose dire presque trollesquement) mais bien orienté pour le PO.

Si on développe sous visual 2008/2KT tu conseils donc de linker la libstl de apache plutot que d'utiliser celle de visual ? (si c'est possible j'ai un doute que l'on puisse avoir le choix en faite)

[Goten]

Pour avoir développer pendant 2 ans sur PS3 et Blade Q22, le principale probleme est que le libstd de ces plateforems fait genre entre 1.2M et 4M ...
Sachant que sur PS3, les SPE du processeur Cell ont 256K de scratchpad, c'ets un peu la loose. Personnelement, ca ne m'empecher pas d'utiliser la STL, suffisait de jamais inclure des trucs genre <{i,o,f,s}stream>. Itou avec Boost, tt passe sauf les trucs avec des .a garrgantuesques.

C'est quoi la SL qu'ils utilisent ? Du bon vieux NIH ?

@screetch : ouai, ça confirme bien ce que j'avais entendu, c'est quoi le compilo?


@guillaume07 : aucune idée j'utilise pas VS. (Et leur implémentation est pas mal, basé sur celle de dikumware si mes souvenirs me trompent pas, mais ils prennent juste un peu trop de liberté à mon goût... enfin, ça va en s'améliorant).

[koala01]

Si on développe sous visual 2008/2KT tu conseils donc de linker la libstl de apache plutot que d'utiliser celle de visual ? (si c'est possible j'ai un doute que l'on puisse avoir le choix en faite)

Sous Gcc, par exemple, c'est possible, bien que cela nécessite quelques acrobaties à savoir:

Au lieu de compiler ton code C++ avec g++, le compiler avec gcc, en précisant qu'il s'agit d'un code C++ et en indiquant explicitement les chemins d'accès vers les fichiers relatifs à la lib apache, sans oublier de linker avec la dite bibliothèque.

Gcc (par opposition à g++ qui est le compilateur spécifique pour le C++) est en effet capable de compiler du code C++ sans prendre en compte les réglages relatifs au compilateur spécifique en ce qui concerne les fichiers d'en-tête et les bibliothèques (qui doivent donc être explicitement indiqué grâce aux paramètre -I (i majuscule), -L et -l (L minuscules) ) de manière automatique dés que les fichiers d'implémentation présentent une extension connue pour être spécifiquement dédiée au C++ (*.cpp, *.cxx, ...) ou de manière explicte avec l'option -x

Il faudrait juste voir si Visual C(++) est capable de la même gymnastique

Il faudrait voir

[screetch]

C'est quoi la SL qu'ils utilisent ? Du bon vieux NIH ?

@screetch : ouai, ça confirme bien ce que j'avais entendu, c'est quoi le compilo?


@guillaume07 : aucune idée j'utilise pas VS. (Et leur implémentation est pas mal, basé sur celle de dikumware si mes souvenirs me trompent pas, mais ils prennent juste un peu trop de liberté à mon goût... enfin, ça va en s'améliorant).

GCC ou un dérivé proprietaire de sony. Le problème serait plutot le linker apparemment, mais il semble aussi que le code généré soit légèrement différent (sauvegarde des registres...) ce qui est un peu con.

[sleepless]

Je viens de tester code::blocks/gcc. Un peu dépaysé mais ça valait le coup : gcc voit des choses pas jolie que builder avait laissé passé silencieusement, et en plus il fait gagner 45% de performance à mon appli

Par contre, je n'ai toujours pas trouvé quelle version de gcc était utilisé dans code::blocks, donc je n'ai pas pu vérifier de quand elle date. Ais-je un enfin un "vrai compilateur" entre les main maintenant ?

Pour en revenir à ma question initiale, même si je vais me passer de l'amitié et laisser le compilateur optimiser comme ça m'a été conseillé, j'aimerai quand même bien trouver la bonne syntaxe, juste par curiosité ! Add, Add<>, Add<taille>, Add<Objet, Taille> aucune de ces syntaxes ne compile avec gcc !

@koala01 : Merci de tes explications. Ca n'est pas que je me soit senti attaqué sur mes capacités, ni que je me crois doué d'un quelconque génie, mais juste que je pensais que c'était à la porté du programmeur moyen. Pour moi, il ne s'agissait que d'un bête tableau à encapsuler, mais apparemment, je sous estime de beaucoup la complexité du problème, et les subtiles optimisation auxquels il se prête. Que du code générique puisse être plus performant que du code dédié à un cas particulier, c'est quand même contre-intuitif non ? Cela dit, c'est peut être surprenant, mais c'est plutôt une bonne surprise : ça veut dire que je peut mettre la STL à toute les sauces, et gagner du temps sans perdre de performance

[koala01]

Je viens de tester code::blocks/gcc. Un peu dépaysé mais ça valait le coup : gcc voit des choses pas jolie que builder avait laissé passé silencieusement, et en plus il fait gagner 45% de performance à mon appli

Par contre, je n'ai toujours pas trouvé quelle version de gcc était utilisé dans code::blocks, donc je n'ai pas pu vérifier de quand elle date. Ais-je un enfin un "vrai compilateur" entre les main maintenant ?

A vrai dire, je "joue" avec les nigthly builds de code::blocks et les versions de mingw compilées par mes soins depuis tellement longtemps que je ne sais plus trop quelle est celle utilisée par CB

Cependant, tu peux lancer la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc -v

(dans la ligne de commande (menu démarrer->accessoires->invite de commandes) ) pour obtenir le numéro de version de gcc (le résultat termine par gcc version: X.Y.Z ... )

Il me *semble* qu'ils sont passés à une version 4.3.x ou 4.4.x de gcc, mais je n'en suis pas sur du tout.

Il n'y a vraiment que si tu obtiens un résultat proche de la version 3.x.y qu'il serait intéressant d'envisager de passer à une version supérieure

Mais cela se fait *relativement* facilement

@koala01 : Merci de tes explications. Ca n'est pas que je me soit senti attaqué sur mes capacités, ni que je me crois doué d'un quelconque génie, mais juste que je pensais que c'était à la porté du programmeur moyen. Pour moi, il ne s'agissait que d'un bête tableau à encapsuler, mais apparemment, je sous estime de beaucoup la complexité du problème, et les subtiles optimisation auxquels il se prête. Que du code générique puisse être plus performant que du code dédié à un cas particulier, c'est quand même contre-intuitif non ?

D'après ce que j'en sais, std::sort est plus performant que qsort, c'est te dire

C'est effectivement contre intuitif lorsque l'on aborde les choses en surface, mais il faut savoir qu'il est possible, sur un code générique, de rajouter des politiques, des spécialisations partielles ou complètes et d'utiliser un tas d'autres techniques qui permettent, justement, de s'assurer qu'un différent sera utilisé dans une situation particulière.
Si, en plus, on se souvient qu'une grande partie des vérifications est effectuée à la compilation et non à l'exécution, on fini par se rendre compte qu'il y a, effectivement, pas mal de choses qui sont faites avant l'exécution, et que tout cela influera énormément sur les performances générales

Cela dit, c'est peut être surprenant, mais c'est plutôt une bonne surprise : ça veut dire que je peut mettre la STL à toute les sauces, et gagner du temps sans perdre de performance

A peu de choses près, oui...

Il faut cependant savoir que certaines parties, dont les flux sont loin d'être parfaitement optimisées...

Mais, en règle générale, tu peux, effectivement considérer que la première chose qu'il faut revoir si tu es confronté à un problème de performances, ce sont tes algorithmes et tes décisions d'utiliser un conteneur plutôt qu'un autre, puis tes algorithmes et tes décisions d'utiliser un conteneur plutôt qu'un autre et encore tes algorithmes et tes décisions d'utiliser un conteneur plutôt qu'un autre.

Ce n'est que si tu rencontre encore un problème de performances une fois que tu as la certitude d'utiliser l'algorithme "optimal" (pour autant qu'il existe) avec le conteneur le plus adapté à ton problème qu'il peut valoir la peine de s'intéresser aux performances brutes de ce que le standard propose

[Joel F]

GCC ou un dérivé proprietaire de sony. Le problème serait plutot le linker apparemment, mais il semble aussi que le code généré soit légèrement différent (sauvegarde des registres...) ce qui est un peu con.

En gros, spu-ld est très très très mauvais :s
Y a des cas ou si tu as besoin de foo.o qui vit dans libbar.a et quel el .a contient 78978 autres symboles que tu n'utilsies pas, il link tout comme un cochon.