Le but premier de la mise au point d'un programme consiste à s'assurer du fait que les algorithmes exprimés effectuent bien le traitement tel qu'imaginé par le programmeur.
Pour cela, il est assez courant d'avoir recours à un outil de débogage (comme nous l'avons expérimenté dans cette section, celle-ci, celle-ci et celle-ci), pour exécuter le code pas-à-pas, atteindre des points d'arrêt, inspecter la pile d'exécution et les variables...
Il est donc indispensable que le code exécutable généré soit une traduction très fidèle, quasiment mot-à-mot, du code source.
Dans ces conditions, chaque progression de quelques instructions dans le code exécutable correspond à une progression facilement identifiable dans le code source.

En recherchant, dans le fichier GNUmakefile fourni, la prise en compte de la variable opt lorsqu'elle vaut 0, vous devriez constater sans surprise que l'option -g sera indiquée au compilateur.
Nous avons en effet déjà vu qu'elle provoque l'ajout aux fichiers objets produits, et donc au fichier exécutable qui les rassemblera, des informations permettant de faire le lien entre le code exécutable et le code source.
De plus, l'option -O0 indique au compilateur qu'aucune optimisation ne doit avoir lieu afin que le code exécutable généré soit très peu transformé par rapport au code source.
Vous avez déjà eu l'occasion d'expérimenter le débogueur dans ces conditions.

À titre d'illustration, reprenez une des expérimentations précédentes et refabriquez-la avec make rebuild opt=1.
Vous devriez constater que l'exécution dans le débogueur ne permet plus de faire le lien avec le code source.

La prise en compte de la variable opt du fichier GNUmakefile lorsqu'elle vaut 0 introduit également l'option -UNDEBUG.
Le préfixe -U est équivalent à la directive #undef du préprocesseur : dans le cas présent, nous supprimons donc la macro NDEBUG au cas où elle serait définie (par une option préalable par exemple).
La présence ou l'absence de la macro NDEBUG (signifiant no-debug, pas de débogage) influence le comportement de la fonctionnalité assert(). (https://en.cppreference.com/w/c/error/assert)

Il s'agit d'une macro définie dans le fichier d'en-tête standard

<assert.h>

dont le rôle est de terminer brutalement le programme avec abort() (précédé d'un message explicite) si l'expression qui lui est transmise en paramètre est fausse.
Seulement, cette macro se réduit à néant, et donc n'a aucun effet, si la macro NDEBUG est définie.
L'intérêt est de tenter de détecter, pendant la phase de mise au point d'un programme (avec NDEBUG non définie donc), le plus grand nombre d'incohérences potentielles (des préconditions sur les paramètres d'une fonction par exemple).
Ces vérifications peuvent être coûteuses en temps d'exécution, c'est pour cela qu'elles sont supprimées (avec NDEBUG définie) lorsque le programme est considéré comme suffisamment au point et que nous souhaitons en produire une version optimisée.

À titre d'illustration, reprenez une des expérimentations précédentes, et faites usage de assert() avec une condition que vous savez être fausse.
Observez alors le changement de comportement de votre programme selon qu'il est compilé pour la mise au point ou pour l'optimisation.

Il existe des maladresses qui sont difficiles à détecter explicitement car elles peuvent être dues à une inattention ou une erreur de saisie.
Elles peuvent provoquer, par exemple, la sortie d'un tableau lors de son parcours, l'usage d'un pointeur non initialisé, un mauvais usage de l'allocation dynamique, une fuite mémoire, le dépassement inattendu de la capacité d'un entier...
Il est peu probable dans ces conditions que nous puissions utiliser assert() pour tenter de les détecter : il faudrait le faire absolument partout !

Heureusement, les compilateurs modernes offrent désormais des options pour produire automatiquement énormément de code qui tente de détecter de telles maladresses lors de l'exécution afin de nous les signaler au plus tôt.
La prise en compte de la variable opt du fichier GNUmakefile lorsqu'elle vaut 0 introduit également l'option -fsanitize=address,undefined sur les plateformes qui la supportent.
La documentation du compilateur indique une grande variété d'options pour ces vérifications : $ man gcc ↵ (c'est très long, monter/descendre avec les flèches, quitter avec la touche q)

À titre d'illustration, reprenez une des expérimentations précédentes qui utilise un tableau (dynamique ou non), et modifiez temporairement un algorithme de parcours pour qu'il effectue une itération surnuméraire (

<=

à la place de

<

sur la condition de la boucle par exemple).
Observez alors le changement de comportement de votre programme selon qu'il est compilé pour la mise au point ou pour l'optimisation.
Lors de la mise au point, l'exécution s'arrête avec un message explicite au moment où notre programme tente un accès au delà du tableau.
Au contraire, dans le cas d'un code optimisé cette maladresse passe inaperçue au moment où elle est commise ; si elle doit avoir des conséquences, celles-ci ne seront visibles que bien plus tard et il sera difficile de remonter à l'origine du problème.

Toujours dans le but d'expérimenter, reprenez une expérimentation qui fait usage de l'allocation dynamique de mémoire et retirez temporairement un appel à la libération d'un bloc mémoire devenu inutile.
Lors de la mise au point, à la fin de l'exécution du programme un message vous informe de cet oubli et vous indique même où l'allocation a eu lieu dans le code.
Au contraire, dans le cas d'un code optimisé cette maladresse passe totalement inaperçue ; seul l'accroissement démesuré de la mémoire consommée par un tel programme qui commettrait cette maladresse de manière répétée pourrait éveiller notre attention.

Une toute autre maladresse que vous devez tester consiste à affecter à un entier une valeur proche de INT_MAX puis à lui ajouter une quantité de telle façon que cette limite devrait être dépassée.
Si nous fabriquons le programme pour la mise au point, un message est produit à l'exécution lorsque ce comportement indéfini (dépassement de la capacité d'un entier signé) est détecté.
Au contraire, dans le cas d'un code optimisé, cette maladresse passe totalement inaperçue ; seul l'aspect éventuellement aberrant des résultats de calcul du programme suite à ce dépassement de capacité pourrait éveiller notre attention✍.

Tous les exercices qui vous ont été proposés dans le cadre de cet enseignement insistaient sur la nécessité d'écrire des programmes de test des fonctionnalités réalisées.
Cette démarche doit être systématique et doit faire usage de tous les outils d'aide à la mise au point présentés ici.
Ce n'est que lorsqu'on est absolument certain que ces fonctionnalités se comportent comme attendu qu'il est envisageable d'en accélérer l'exécution.
En effet, l'optimisation réalisée par le compilateur consiste à retirer du code produit toutes les vérifications désormais superflues pour ne laisser que les instructions qui sont strictement nécessaires aux traitements utiles.
Ceci passe de plus par une reformulation profonde de ces derniers, de telle façon qu'ils produisent le même effet observable mais selon un enchaînement d'opérations qui soit optimal pour le processeur.
Dans ces conditions il n'y a quasiment plus moyen de faire le lien entre les détails du code exécutable et ceux du code source original, ce qui interdit toute démarche de mise au point.

La prise en compte de la variable opt du fichier GNUmakefile lorsqu'elle vaut 1 introduit, parmi les nombreuses autres transmises au compilateur, ces options liées à l'optimisation :

-O3 -DNDEBUG -fomit-frame-pointer -ffast-math -march=native

Elles s'interprètent de la façon suivante : Bien entendu, l'usage de ces options et de nombreuses autres est toujours discutable et dépendant du contexte applicatif visé ; il ne s'agit ici que d'exemples très classiques.

Une première précaution triviale à considérer, en vue d'accélérer l'exécution d'un traitement, consiste à éviter d'invoquer de manière répétée des opérations dont nous savons qu'elles produiront systématiquement le même effet.

Expérimentons ceci sur un exemple simpliste rendu volontairement très maladroit.
Cette fonction Perf_alphaCount() doit être fournie par le module perf : Elle parcours entièrement la chaîne txt et compte à chaque fois qu'un caractère alphabétique (une lettre, voir cette section) est rencontré.
Le programme principal contiendra ces fonctions : La fonction now() utilise une fonctionnalité du système d'exploitation pour relever l'instant courant ; en procédant par différence, nous pouvons alors estimer la durée écoulée entre les appels à cette fonction.
La variable txt de test_alphaCount() est initialisée avec une très longue chaîne ; celle-ci est obtenue par la macro TXT_x30 qui se contente de répéter trente fois la macro TXT qui elle même représente une longue chaîne littérale.
La boucle for() est assez élaborée dans le sens où elle combine à la fois le comptage des itérations et le contrôle du temps écoulé.
La mesure des performances repose sur un très grand nombre de répétitions du traitement Perf_alphaCount() à étudier, jusqu'à ce que la durée constaté soit suffisamment longue (plus de deux secondes ici) pour qu'une mesure moyenne en nombre d'itérations par secondes ait du sens.

La fonction principale doit faire appel à la fonction test_alphaCount() afin que l'exécution de ce programme affiche les performances de la fonction Perf_alphaCount().
Fabriquez ce programme avec les options de mise au point et exécutez-le afin de vous assurer de son bon fonctionnement.
Relevez alors plusieurs fois ses performances, et reprenez ceci avec les options d'optimisation : vous devez déjà constater un gain de performances énorme.
Ceci met en évidence le fait qu'il n'est absolument pas pertinent de s'intéresser aux performances d'un traitement s'il n'est pas compilé avec les options d'optimisation.

Nous évoquions en introduction de cet exemple une maladresse grossière : en effet, l'évaluation de Perf_len() a lieu pour chaque caractère considéré dans la fonction Perf_alphaCount().
Or, en tant que concepteur de ce traitement, nous savons pertinemment que la longueur de la chaîne n'a aucune raison de changer d'une itération à la suivante.
Il est donc inutile de réévaluer cette longueur pour chaque caractère visité ; de plus, Perf_len() est un traitement assez coûteux puisqu'il s'appuie sur la fonction standard strlen() qui parcourt toute la (très longue !) chaîne jusqu'à détecter le caractère nul (voir cette section).
Modifiez alors la boucle de la fonction Perf_alphaCount() afin que Perf_len() ne soit invoquée qu'une seule fois et que son résultat soit mémorisé dans une variable qui sera consultée dans la condition de cette boucle.
Vous pouvez conserver les deux versions en jouant sur des commentaires ou avec une compilation conditionnelle afin d'alterner entre ces deux solutions.
Reprenez alors les tests et les mesures de performances avec cette nouvelle version.
Vous devriez constater que le retrait de cette maladresse grossière est très bénéfique pour les performances, que ce soit en mise au point ou en optimisation.

Il ne s'agit ici que d'un cas particulièrement évident mais la démarche se généralise : à chaque fois qu'une boucle est réalisée, il faut s'interroger sur ce qui donne systématiquement le même résultat à chaque itération et le sortir de cette boucle en le mémorisant dans une variable qui sera réutilisée dans la boucle.
Il est à noter toutefois que les compilateurs modernes sont parfois capables de faire ce travail automatiquement lorsque le contenu de la boucle est facile à analyser, mais rien n'est garanti cependant à ce sujet.
Sur cet exemple particulier ce n'est pas le cas car le compilateur ne pousse pas l'analyse jusqu'à constater que la fonction Perf_len() ne fait qu'invoquer la fonction standard strlen() sur une chaîne que nous ne modifions pas✍ ; il se garde donc de supposer que le résultat sera identique à chaque invocation.

La dernière remarque exprimée doit attirer votre attention sur le fait que le compilateur est capable de reformuler automatiquement un algorithme s'il est certain que la version modifiée produira exactement le même résultat que la version originale.
S'il n'est pas en mesure de prouver cette équivalence, il adoptera au contraire une attitude très conservatrice dans le sens où sa première priorité est de produire un code exécutable qui aboutisse exactement au même résultat que ce qui est exprimé dans le code source.
Cela doit nous encourager à fournir au compilateur la meilleure vision possible du traitement réalisé par l'algorithme que nous exprimons.

Nous avons déjà rencontré dans cette section la définition de fonctions qualifiées de inline static, ce qui correspond exactement à cette attente : puisque le compilateur voit le code de la fonction appelée à l'endroit de son appel, il sait exactement ce que la fonction fait et peut en déduire les interactions potentielles avec les données du contexte appelant. Lors de l'analyse du code de cet exemple, si la définition de la fonction doSomething() n'est pas visible, le compilateur n'est alors pas en mesure de prouver que la donnée située à l'adresse désignée par le pointeur p ne sera pas modifiée par cet appel.
Il y aura donc un premier accès à cette adresse pour calculer la variable a puis, plus tard, un second accès pour calculer la variable b.

Supposons maintenant que la définition de la fonction doSomething() soit visible et qu'elle n'ait aucune influence sur ce qui est désigné par le pointeur p.
Dans ces nouvelles conditions, le compilateur pourrait prendre la liberté de reformuler le code précédent de cette façon : Selon cette nouvelle formulation, un seul accès à l'adresse indiquée par le pointeur p a lieu et la valeur tmp est directement réutilisée dans les calculs de a et b, ce qui se révèle probablement plus efficace✍.

Il pourrait alors être tentant de qualifier toutes les fonctions de inline static mais ce serait contre-productif.
En effet, le code de ces fonctions est dupliqué dans le programme exécutable à chaque invocation, ce qui produit un code beaucoup plus volumineux, et la taille du code peut avoir une influence très négative sur les performances✍.
Nous réservons donc le qualificatif inline static aux fonctions qui ne sont constituées que de très peu d'opérations.

Toutefois, toujours dans le contexte de notre exemple précédent, même si la définition de la fonction doSomething() n'est pas visible du compilateur lors de son appel, le développeur, lui, sait certainement très bien pourquoi il invoque cette fonction et quel en est l'effet attendu.
Il sait donc parfaitement si cette invocation est susceptible de modifier ce qui se trouve à l'adresse désignée par le pointeur p ou non.
Dans ce dernier cas (le plus probable), c'est donc au développeur de formuler l'algorithme en levant explicitement l'ambiguïté par l'usage d'une variable (tmp ici) qui mémorise le résultat d'un unique accès à l'adresse indiquée (par p ici).

La démarche illustrée par cet exemple doit systématiquement être généralisée : il faut rendre explicite au compilateur ce que nous savons mais qu'il ne peut déduire de la simple analyse du code visible localement✍.
Ceci passe notamment par l'usage de variables pour mémoriser des résultats plutôt que de recourir à de multiples évaluations qui donneraient des résultats identiques, ce qui rejoint la recommandation formulée plus haut.
Cette recommandation est particulièrement pertinente lorsque des pointeurs sont utilisés, car le compilateur a généralement une mauvaise visibilité sur ce qui est susceptible d'interagir avec la donnée désignée.
La règle suivante sera alors appliquée : nous nous interdisons d'accéder plusieurs fois à la même adresse avec un pointeur si la valeur désignée ne doit pas être différente.

De la même façon, il faut éviter de réutiliser la même variable pour des calculs qui sont indépendants.
Il n'y a en effet rien à gagner d'une telle économie supposée de variable✍ : les variables ne représentent qu'une abstraction pour exprimer les algorithmes.
Elles n'ont, pour la plupart, pas d'emplacement en mémoire (sauf si on cherche explicitement à en connaître l'adresse) car l'optimisation par le compilateur peut les faire disparaître (au profit d'une mémorisation dans les registres du processeur) ou au contraire en créer de nouvelles pour stocker les résultats intermédiaires de longs calculs.
La réutilisation d'une même variable risque de créer artificiellement une dépendance entre des calculs qui sont en réalité indépendants.
Dans ces conditions, le compilateur s'interdira de remanier ces calculs de manière plus efficace si, lorsque l'algorithme n'est pas trivial, il ne peut prouver que les résultats ne s'en trouveront pas modifiés.
Si au contraire, nous prenons soin d'utiliser des variables distinctes pour des calculs distincts, nous n'introduisons pas de dépendances artificielles entre ces calculs et le compilateur aura toute l'opportunité de les réorganiser de manière plus efficace.

Pour aller plus loin dans l'explicitation de nos intentions, il est recommandé de qualifier avec const les variables pour lesquelles nous savons qu'aucune modification ne doit avoir lieu (pas seulement les données désignées par des pointeurs comme indiqué dans cette section).
Cette information peut aider le compilateur dans son analyse du code et lui offrir plus de latitudes dans les reformulations qu'il peut envisager✍.

Nous avons évoqué dans cette section le fait que la représentation en complément-à-deux permettait de réaliser les opérations arithmétiques sur les entiers signés de la même façon que sur les entiers non-signés.
Il est donc peu probable que l'exécution de ces opérations par le matériel ait des performances différentes dans le cas signé ou non-signé.
Cependant, nous avons également indiqué dans cette section que le débordement de capacité sur un entier non-signé avait un comportement parfaitement défini (le rebouclage vers l'autre extrémité de la plage de valeurs), alors que ce comportement est indéfini sur un entier signé.
C'est la distinction entre ces comportements, défini ou indéfini, qui peut avoir une influence sur l'optimisation des algorithmes, notamment lorsque ces entiers servent d'indices pour accéder à des données.

Expérimentons ceci en ajoutant cette fonction au module perf. Elle réalise dans cMtx le produit de la matrice aMtx par la matrice bMtx ; toutes ces matrices sont carrées, de côté size.
Remarquez que le type du paramètre size, des compteurs de boucles et des indices de tableaux est inconnu pour l'instant ; nous devons le décrire dans le fichier perf.h. Le programme principal contiendra cette fonction : Elle repose sur le même principe que la fonction test_alphaCount() pour évaluer cette fois-ci les performances de la fonction Perf_mtxProduct() sur des matrices de côté 100.

La fonction principale doit faire appel à la fonction test_mtxProduct() afin que l'exécution de ce programme affiche les performances de la fonction Perf_mtxProduct().
Après en avoir testé le fonctionnement en l'ayant fabriqué pour la mise au point (make rebuild opt=0), fabriquez à nouveau ce programme pour l'optimisation (make rebuild opt=1) et relevez plusieurs fois les performances reportées.

Avant d'aborder la problématique du type index_t artificiellement introduit ici, intéressons nous au commentaire sur la maladresse introduite dans la fonction Perf_mtxProduct().
Cette formulation va effectivement à l'encontre de la règle que nous énoncions plus haut concernant l'usage répété d'un pointeur désignant la même donnée : à chaque itération selon l'indice k, nous modifions le même élément de cMtx.
Adaptez alors cette boucle de cette façon : La compilation conditionnelle nous permettra d'alterner, lors de nos expérimentations, entre les deux formulations envisagées ici.
Dans la nouvelle formulation nous faisons usage d'une variable qui accumule les incrémentations successives pour finir par une écriture unique du résultat sur l'élément de cMtx concerné✍.
Après avoir testé le fonctionnement de cette nouvelle formulation en l'ayant fabriqué pour la mise au point, fabriquez à nouveau ce programme pour l'optimisation et relevez plusieurs fois les performances reportées.
Vous devriez constater une certaine amélioration de ces dernières par rapport à la formulation précédente✍.

Intervenez maintenant sur le type index_t dans le fichier d'en-tête (avec des commentaires ou la compilation conditionnelle) afin qu'il soit dorénavant équivalent au type int ; il était non-signé jusqu'alors et devient désormais signé.
Reprenez les mesures de performances avec et sans la maladresse liée à l'absence de la variable d'accumulation discutée précédemment.
Dans ces nouvelles conditions vous devriez constater un nouvel accroissement des performances, et notamment de manière très significative lorsque la variable d'accumulation est utilisée.

L'explication repose uniquement sur le fait que, comme indiqué dans cette section, le débordement de capacité sur un entier signé donne un comportement indéfini : un algorithme qui utilise des indices signés ne peut en aucune façon être considéré comme correct si ces indices subissent un débordement de capacité.
Par conséquent, à l'analyse du code, le compilateur peut supposer que l'incrémentation d'un indice signé ne pourra jamais donner un indice inférieur : le programme aurait alors un comportement indéfini.
Avec des indices non-signés, il serait au contraire tout à fait légitime de s'appuyer sur le fait que les indices trop grands rebouclent vers zéro et le compilateur ne pourrait donc pas supposer impossible qu'un indice devienne inférieur suite à son incrémentation.
Cette propriété fait que, dans le cas d'indices signés le compilateur peut reformuler le code en supposant qu'un tel rebouclage ne peut pas légitimement se produire, alors qu'il s'interdira de faire cette supposition (même si dans les faits le cas ne se présente pas) avec des indices non-signés.

Au bout du compte, nous constatons une reformulation bien plus efficace de l'algorithme par le compilateur, non pas parce que les opérations arithmétiques sur les entiers signés sont plus rapides (elles ne le sont absolument pas !), mais parce que le compilateur se débarrasse de précautions superflues (l'éventualité de la non-contiguïté des données) lorsqu'il organise les accès à la mémoire.
La règle suivante sera désormais appliquée : nous utilisons systématiquement des entiers signés sauf dans quelques cas très rares où l'usage d'entiers non-signés représente un aspect essentiel du problème (pour les opérations bit-à-bit par exemple)✍.

Remarquez également qu'aucune des deux interventions proposées ici (utilisation d'un accumulateur local pour éviter la répétition d'une indirection identique et utilisation d'indices signés) ne suffit à elle seule pour obtenir une amélioration significative.
C'est bien l'utilisation simultanée de ces deux précautions qui nous permettent d'obtenir ici le gain de performances attendu.
Il convient de considérer de telles précautions non pas comme des optimisations en elles-mêmes mais comme l'évitement de maladresses qui empêcheraient le compilateur d'optimiser pleinement le code exécutable ; tant qu'il reste de telles maladresses le compilateur est bridé dans ses actions et ce n'est que lorsqu'elles ont toutes disparu que l'optimisation du compilateur peut pleinement s'exprimer.