Que ce soit de l´implémentation d´un algorithme mathématique, ou du choix de certains opcodes plus que d´autres.
-L´algorithmie THÉORIQUE. J´inclus dans cette catégorie tout algorithme sur papier, dont l´implémentation est sujette à variation. Cela peut-être par exemple la simplification d´un algorithme mathématique, ou d´autres techniques pour faire varier le fonctionnement à l´interne ( le choix de certaines technologies plutôt que d´autres et leur intégration).
Cette dernière catégorie est sujet à naître de son créateur et hors de portée du compilateur. Je n´en ferai pas mon sujet principal, et me concentrerai plutôt sur le premier type.
En ce qui concerne l´algorithmie du CODE, dont je me défend bien d´y affubler le terme de Logiciel ou Pratique, est ce qui peut-être touché au niveau du code, et donc, la cible pour tout optimiseur de tout acabit, y compris ceux inclus dans tout compilateur digne de ce nom.
Cet algorithmie est très fortement en lien avec l´assembleur qui est mon principal sujet d´intéret, car il est au centre des résultats. Mon but ici n´est en effet pas d´analyser la base, mais plutôt de voir le travail du compilateur en matière d´optimisation du code.
Premièrement, ces résultats peuvent varier sensiblement avec le choix de certains composants. J´entend par là que le choix de certains opcodes par rapport à d,autres font varier le résultat.
Mais dès lors, jusqu´à quel point un simple opcode peut-t-il changer les choses?
Pas grand chose, généralement. c,est plutôt l´utilisation judicieuse d´une bonne COMBINAISON d´opcodes. Ce que j´entend par là, c,est qu´au niveau optimisation, l´intéret est de considérer l´optimisation sur un plus grand ensemble possible. Et que, optimiser une zone petite peut admettre des meilleures performances par exemple dans cette petite zone, mais baisser les performances plus globables d´un ensemble dont elle fait parti, parce que ces autres opcodes, pour garantir la meilleure optimisation possible, se base sur les autres opcodes. Donc c´est de l´entre-aide entres opcodes qui garantit un bon rendement.
Note que plus l,ensemble est grand, plus on serait tenté de penser que le gain se joue plutôt avec le high level, car ils permettent une plus grande zone de visuel sur le code. Ce n,est pas nécessairement vrai. Les vrais rouages peuvent ainsi se jouer de manière subtile ( mais tangible au niveau des résultats) dans l´implémentation d´opcodes d´un language plus haut niveau comme le C++ par exemple.
J´en reviens à notre sujet actuel de différent:
le compilateur fait mieux le boulot que nous, s,amuser à jouer avec le rendu asm est inutile, ou alors, franchement ridicule.
J´en reste à ma position précédente: c´est faux.
Les compilateurs ont un gros problème en matière d´optimisation:
Leur champ de vision est maigre. Qu´entend-je par là? J´en entend qu´ils ne se concentre que sur des bouts petits de code, les uns par les uns, au lieu de se concentrer sur l´assemblage général de ces bouts.
De plus, ils leur viennent un autre défaut majeur:
ils évalent toutes les possibilités. Ils évalent tous les choix possibles sur ce léger groupe d´opcodes, et ils ne peuvent pas faire grand chose d´autre. Pourquoi? Parce que l´informatique est faite de cette fâçon! L´informatique est basé sur le principe de faire tout stupidement, mais très rapidement. Un processeur est un esclave stupide hyper-performant!
La solution est évidente: l´IA. La soltuion est l´intelligence, qui permet de ne considérer que les choix qui ressortent comme étant optimisables.
C´est d´ailleurs ce qui me pousse à croire, entres autres, que nous sommes plus efficaces: nous ne faisons pas que d´exécuter de simples assemblables de commandes prédéterminées ( remplacer la multiplication *2 par un shift systématiquement), mais nous somme capables d´extrapoler des cas, d´assembler des cas pour en produire un shéma d´optimisation comparable au cas actuel dont nous tentons l´amélioration.
Donc, revenons à l´IA. J´introduit ce sujet car il me parrait évident qu´il s´agit de la soltuion. En fait, ça existe déjà au niveau des compilos: mais elle est très basique, et faite pour AIDER la technique de l´esclave stupide et performant, que plutôt la remplacer.
Le problème avec cet esclave, c´est qu´il perd du temps. Et il en perd exponentiellement de plsu en plus si la taille de sections à analyser est grand. On doit donc trouver une limite entre l´optimisation, sa vitesse et la taille de sections à analyser, pour trouver le meilleur ratio qualité d´optimisation/temps pris pour l´obtenir.
C´est en fait un des grand obstacles contre ce choix des plus évidents qui est de considérer un ensemble plus gros à optimiser.
Nous souffrons bien moins de ces problèmes. Notre intelligence nous permet un avantage conséquent face au compilateur.
Pendant que j´y pense, niveau respect, ça faiblit un peu de ton côté. Je pense entres autres à ton dédain pour les personnes qui ne respectent pas ton point de vue sur le sujet de l´optimisation manuelle:
" Ce qui me fait bien rire, ce sont les gens [...]"
" Maintenant, si tu veux t´amuser à bugguer ton code, le rendre illisible pour gagner 3 cycles d´horloge..."
Je respecte tes opinions, mais si je ne les partages pas. Fais en donc de même, et le débat ne s´en portera que mieux.
Kelios
---------
