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.
3 |
0 |
Envoyé par Bousk
