Techniques d'optimisation pour C ++

Question

Dans son discours, il y a quelques jours sur Facebook - diapositives, vidéo, Andrei Alexandrescu parle du commun des intuitions qui pourrait prouver que nous avons tort. Pour moi un point très intéressant est venu sur la Diapositive 7, où il affirme que l'hypothèse "Moins d'instructions = plus rapide code" n'est pas vrai, et plus d'instructions ne sera pas nécessairement plus lente code.

Voici mon problème: La qualité audio de son discours (autour de 6:20min) n'est pas bien et je ne comprends pas l'explication très bien, mais de ce que j'ai, c'est qu'il compare à la retraite instructions avec l'optimalité de l'algorithme sur un niveau de performance.

Cependant, à partir de ma compréhension, ce ne peut pas être fait, parce que ce sont deux niveaux structurels. Des Instructions (surtout en fait à la retraite instructions) sont une mesure très importante et, fondamentalement, vous donne une idée de la performance pour atteindre un but. Si l'on exclut le temps de latence d'une instruction, on peut généraliser que de moins en moins à la retraite instructions = plus rapide du code. Maintenant, bien sûr il y a des cas où un algorithme qui effectue des calculs complexes à l'intérieur d'une boucle d'obtenir de meilleurs performances, même si elle est effectuée à l'intérieur de la boucle, car il va se casser la boucle antérieure (pensez graphique de la traversée). Mais ne serait-il pas plus utile de comparer les algorithmes sur un niveau de complexité plutôt que de dire cette boucle a plus d'instructions et c'est mieux que l'autre? De mon point de vue, le meilleur algorithme aura de moins en moins à la retraite des instructions à la fin.

Quelqu'un peut-il m'aider à comprendre où il voulait en venir son exemple, et comment peut-il y avoir un cas où (beaucoup) plus à la retraite instructions conduire à de meilleures performances?

Answer 1

La qualité est en effet mauvais, mais je pense qu'il a conduit au fait que les Processeurs sont bonnes pour les calculs, mais souffrent d'une mauvaise performance de la mémoire chercher (RAM est beaucoup plus lent que le CPU), et les branches (en raison de l'UC fonctionne comme un pipeline, et les branches peuvent provoquer le pipeline à la pause).

Voici quelques cas où plus les instructions sont plus rapide:

1. Direction de la prévision - même si nous devons faire plus d'instructions, mais il provoque une meilleure direction de la prévision, le pipeline de la CPU sera complet plus de temps, et moins ops sera "jeté", ce qui conduit finalement à une meilleure performance. Ce fil par exemple, montre comment faire la même chose, mais d'abord le tri - améliore performnce.

2. Le Cache CPU - Si votre code est plus de cache optimisé, et suit le principe de localité - il est plus susceptible d'être plus rapide, puis un code qui ne fonctionne pas, même si le code ne fait pas la moitié de la quantité d'instructions. Ce fil donne un exemple pour une petite cache d'optimisation que le même nombre d'instructions peuvent entraîner beaucoup plus lent que le code s'il n'est pas de cache optimisé.

3. Il a également des questions dont les instructions sont fait. Parfois certaines instructions peuvent être plus lents à effectuer alors que d'autres, par exemple - fracture peut être plus lent que le nombre entier plus.

Remarque: Tous les éléments ci-dessus dépend de la machine et comment/si ils ont fait de modifier les performances peuvent varier d'une architecture à l'autre.

Answer 2

Le nombre d'instructions n'est pas une bonne mesure en soi.

Moins d'instructions retirées (car il n'y a plus rien à faire) = code plus rapide.

Moins d'instructions retirées (car elles doivent attendre les dépendances) = code plus lent.

Il peut parfois arriver que plus d'instructions dans le code signifient également plus d'instructions retirées, car elles peuvent utiliser des créneaux d'exécution qui seraient autrement gaspillés dans le cas 2.