IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

CppCon 2014 – Conception orientée données et C++


Sujet :

C++

  1. #1
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    25 947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 25 947
    Points : 207 567
    Points
    207 567
    Billets dans le blog
    85
    Par défaut CppCon 2014 – Conception orientée données et C++
    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.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    204
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 204
    Points : 525
    Points
    525
    Par défaut
    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)

  3. #3
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 781
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 781
    Points : 31 101
    Points
    31 101
    Billets dans le blog
    4
    Par défaut
    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.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  4. #4
    Membre régulier
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2011
    Messages
    103
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : septembre 2011
    Messages : 103
    Points : 117
    Points
    117
    Par défaut
    Intéressant tout ça, quelqu'un aurait il d'autres ressources à partager concernant cette approche (article, pdf...) ?

  5. #5
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 544
    Points
    544
    Par défaut
    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.

  6. #6
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 781
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 781
    Points : 31 101
    Points
    31 101
    Billets dans le blog
    4
    Par défaut
    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.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  7. #7
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 544
    Points
    544
    Par défaut
    Citation Envoyé par Bousk Voir le message
    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.

  8. #8
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 781
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 781
    Points : 31 101
    Points
    31 101
    Billets dans le blog
    4
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

Discussions similaires

  1. Programation et conception orientée composant ?
    Par El_Diablo666 dans le forum Langages de programmation
    Réponses: 1
    Dernier message: 08/05/2007, 14h46
  2. [archi-débutant]application du concept orienté objet
    Par tookaina dans le forum VB.NET
    Réponses: 2
    Dernier message: 15/01/2007, 13h18
  3. Conception oriente objet
    Par black.out dans le forum OpenGL
    Réponses: 4
    Dernier message: 30/12/2006, 00h15
  4. conception orientée objet
    Par yvon_huynh dans le forum Langage
    Réponses: 1
    Dernier message: 07/08/2006, 13h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo