Discussion :

[LittleWhite]

Mike Acton est directeur du moteur chez Insomniac Games (Sony). Il a notamment travaill� sur Resistance, Rachet & Clanck, Fuse. Il nous parle de la conception orient�e donn�es et des mauvaises id�es voyageant au sein de la communaut� C++.
De plus, il pr�sente aussi comment am�liorer et optimiser le code afin d'obtenir des meilleures performances, notamment en �vitant les cache miss.

Bonne vid�o.

[codec_abc]

Ca a l'air int�ressant et je regarderai en d�tail quand j'aurai le temps. Par contre, il serait judicieux d'enlever la r�f�rence � altdevlog. Le site �tant mort depuis un certain temps (et c'est bien dommage d'ailleurs)

[Bousk]

Pour avoir eu une journ�e de formation avec Mike, c'est hyper int�ressant et �a ouvre tout un domaine, pas �vident � appr�hender, et qui laisse loin derri�re lui la "conception objet" telle que tout le monde la connait.
Mais tout bon programmeur "multi-ressources" (network/multicore/multithread) devrait s'y int�resser.

[flow10000]

Int�ressant tout �a, quelqu'un aurait il d'autres ressources � partager concernant cette approche (article, pdf...) ?

[KsassPeuk]

Lu'!

Le talk est tr�s int�ressant (les questions un poil moins, c'est dommage). Dans l'ensemble, je suis d'accord avec pas mal de trucs mais il y a quelques points qui me chiffonnent un peu.

Je vais surtout tourner autour des 3 mensonges plut�t qu'autour de l'optimisation dans un premier temps :

• le logiciel est une plateforme
• code con�u par rapport au mod�le du monde (je vois pas comment le traduire mieux)
• le code est plus important que les donn�es

Une id�e qui semble centrale dans son d�veloppement est l'id�e que "les abstractions c'est mal", (1) parce qu'on simplifie trop le probl�me, (2) parce que �a rend la maintenance difficile, parce que �a rend la stabilisation plus difficile, (3) parce que �a rend le code plus difficile � pousser en performances.


Les abstractions qui simplifient trop le probl�me qu'on veut traiter (1), c'est un fait, c'est � �viter. Je suis le premier � adh�rer � la citation d'Einstein : "Tout devrait �tre rendu aussi simple que possible, mais pas plus."

Mais il reste quand m�me l'id�e qu'on doit �tre aussi simple que possible, on doit atteindre un niveau d'abstraction tel qu'on capture le probl�me dans son ensemble sans le simplifier. Du coup dire que l'abstraction est pour ainsi dire "nuisible" c'est dommage. On n'a pas besoin � tout moment de conna�tre les donn�es avec toute la pr�cision qu'elles peuvent contenir. Techniquement on peut devenir aussi pr�cis qu'on le veut mais on n'en a pas forc�ment besoin, on va isoler dans les donn�es uniquement la substance qui nous int�resse. On s'abstrait d'une partie de ses caract�ristiques. Bien penser aux donn�es c'est d�j� abstraire pour ne garder que l'utile.

Dans cette optique, l'id�e d'un code con�u par rapport au mod�le du monde, j'ai envie de dire c'est �vident qu'on ne va pas repr�senter dans le code l'exact reflet des interactions r�elles, on va justement s'en abstraire pour ne garder que les interactions qui nous int�ressent dans la r�solution de notre probl�me et �galement en ne gardant que les acteurs qui ont un sens. Mais m�me �a, �a reste une conception de notre abstraction, �a ne nous dit rien sur l'impl�mentation sous-jacente.

Toujours dans les id�es en rapport avec l'abstraction, il y a le fait que le code n'est qu'un outil (r�ponse au troisi�me mensonge). Effectivement, le code c'est l'outil qui nous permet de r�pondre au probl�me, mais le code c'est d�j� bas� sur un/des langage(s), � savoir des abstractions de notre machine. De la m�me mani�re, on passe notre temps � dialoguer avec l'OS, les drivers, des biblioth�ques, ... si �a c'est pas des abstractions de nos plate-formes mat�rielles, c'est quoi ? On passe notre temps � manipuler des abstractions, c'est quand m�me foutrement bizarre de dire qu'elles sont un probl�me. Alors d'une part les abstractions servent (� moins de vouloir recoder les dialogues avec chaque type de contr�leur disque dur qui existe, par exemple) mais d'autre part les softwares comme les OS et les drivers font clairement partie de la plate-forme pour laquelle on d�veloppe : la plate-forme n'est pas que le soft, certes, mais elle n'est pas que le hard non plus.

Apr�s �videmment, il convient de bien doser l'abstraction. Mais dire que (2) l'abstraction rend n�cessairement le code plus difficile � stabiliser et maintenir, je trouve �a un peu gros. Globalement, une solution trop abstraite � un probl�me sera probablement trop impr�cise ou inefficace ... mais instable ? Les codes trop au raz du mat�riel sur de trop larges portions de code sont � mon avis au contraire bien plus durs � stabiliser et maintenir. Apr�s, effectivement abstraire ou g�n�raliser � outrance, �a pose des probl�mes (que certains r�solvent � coups de RTTI ...).

Il y a �galement le point concernant les DPs qu'ils consid�re comme d'horribles nuisibles ... L� honn�tement je ne vois m�me pas quoi commenter, si le pattern modulo quelques l�g�res adaptations calque compl�tement sur notre probl�me, c'est assez dommage de s'en passer. Ouais les DP peuvent �tre mal utilis�s et ruiner un design. De la m�me mani�re qu'on peut mal utiliser une tron�onneuse et se couper les jambes mais c'est pas de la faute de l'outil.


Pour ce qui est de la parties performances, je ne suis pas non plus d'accord sur tous les points.


Dans les choses avec lesquelles je suis parfaitement d'accord on a : l'impl�mentation classique des op�rateurs qui sera g�n�ralement inefficace, les objets avec tout un paquet d'�tat qui sont tout pourris (c'est �galement chiant pour avoir de code lisible et maintenable, et c'est encore une erreur dans l'abstraction), le fait que quand on �crit du code pas terrible, on obtiendra du code compil� pas terrible mais qu'en donnant les bons indices au compilos on peut vraiment l'aider � faire son boulot correctement. Apr�s, il y a l'habituel d�bat AoS vs SoA, on doit optimiser nos structures de donn�es de mani�re � ce que le traitement qui tombe le plus souvent puissent �tre fait de mani�re � bien utiliser les caches mais la question de "lequel il faut prendre ?", c'est pas tranch�, �a d�pend des cas.

On en vient du coup au point correspondant � (3) qui me g�ne vraiment. Ce choix (AoS/SoA) en fonction des cas est diablement facilit� par une bonne abstraction justement. L'exemple qu'il montre avec le dictionnaire est flagrant : on a besoin d'un fournisseur de service qui � une cl� nous associe une valeur. Mais personne ne dit comment �a doit �tre impl�ment� et c'est pr�cis�ment une bonne abstraction qui nous permet de tester plusieurs impl�mentations sous-jacentes et m�me d'optimiser a posteriori sans casser le comportement externe de la classe. La modification du code interne changera peut �tre fondamentalement la pr�visibilit� des performances, mais ce n'est pas d� � l'abstraction, c'est d� au fait qu'on a chang� l'impl�mentation.

Enfin, le petit point � propos des templates et des performances, les templates peuvent ruiner les temps de compilation OK. Mais de l� � dire que �a ruine de mani�re g�n�rale les performances d'un programme, je suis moins convaincu. Ne pas utiliser la SL parce qu'on conna�t bien notre probl�me c'est une chose, mais rien n'emp�che d'�crire du code template et de faire les bonnes sp�cialisations quand elles sont n�cessaires.


Et puis je r�siste pas au plaisir d'un petit troll, � un moment il dit que les codes � abstraction sont plus dur � tester. Les tests c'est pour les faibles, prouvez vos codes.


Voil�, c'est grosso modo ce que je pense de ce talk. Je ne pratique pas le C++ professionnellement, peut �tre que certains (ou tous) des points que je soul�ve sont na�fs, mais m�me si je trouve que la conception orient�e donn�es est un sujet tr�s int�ressant, dire qu'elle est la r�ponse exacte que l'on attend quand on veut de la performances est un peu fort et je trouve que ses arguments ne convainquent pas.

Ciao.

[Bousk]

Bien �videmment Mike parle d'un probl�me que l'on ne rencontre pas tous les jours : l'optimisation d'un moteur de jeu, des probl�mes de temps r�el, etc...
L� o� le cache miss est traqu� et peut te faire perdre 1fps par ci par l�, pas d'un hello world ou d'une application bureau.

Il est pay� et passe sa journ�e � optimiser leur moteur, leurs jeux, pour diff�rents cas, diff�rentes plateformes. Plateformes dont la liste croit r�guli�rement (PS4, XOne, ...), avant de faire disparaitre les plus anciennes.
Son probl�me n'est clairement pas de simplifier un probl�me, mais bien de l'optimiser. Et si l'optimisation passe par une complication, Einstein passera aux oubliettes sans froncer un sourcil.

[KsassPeuk]

Bien �videmment Mike parle d'un probl�me que l'on ne rencontre pas tous les jours : l'optimisation d'un moteur de jeu, des probl�mes de temps r�el, etc...
L� o� le cache miss est traqu� et peut te faire perdre 1fps par ci par l�, pas d'un hello world ou d'une application bureau.

En HPC, tu veux absolument p�ter la tronche � un maximum de cache miss (tout en ayant un minimum de communication), pour autant on ne se d�barrasse pas de toutes les abstractions. Ok, la probl�matique est diff�rente sur le fait qu'on a moins de soucis de temps r�el mais l'id�e de ne plus rien abstraire me semble un poil extr�me.
M�me les noyaux temps r�els s'autorisent des levels d'abstractions (sinon ils seraient inconcevables) pour autant ils font leur boulot.

[Bousk]

http://gdcvault.com/play/1021866/Cod...ic-2015-How-to