Ce qui coûte, ce sont les branchements dont l'issue varie d'un test à l'autre. Si dans ton test d'intérieur de boucle le résultat du test (la valeur du select case) est toujours le même, le cache de prédiction de branchement de ton processeur va faire son travail et réduire la durée de tes branchements à presque rien. Du coup ton code devrait déjà tourner presque à fond de ses capacités.
Tu peux aussi te débarasser du coût d'appel des fonctions en les rendant "statiques" (je ne connais pas l'équivalent en fortran), en gros tu indiques que tes fonction instructions_zero n'est pas prévue pour être appelée en dehors du même fichier .f, et le compilo va remplacer le code d'appel de chaque fonction par le contenu de la fonction elle-même.
Sinon, comme dit au dessus, si tu sors le test des boucles, tu devrais gagner un peu aussi.
# prédiction de branchement
Posté par zerkman . En réponse au message Optimisation de tests dans des boucles. Évalué à 3.
Ce qui coûte, ce sont les branchements dont l'issue varie d'un test à l'autre. Si dans ton test d'intérieur de boucle le résultat du test (la valeur du select case) est toujours le même, le cache de prédiction de branchement de ton processeur va faire son travail et réduire la durée de tes branchements à presque rien. Du coup ton code devrait déjà tourner presque à fond de ses capacités.
Tu peux aussi te débarasser du coût d'appel des fonctions en les rendant "statiques" (je ne connais pas l'équivalent en fortran), en gros tu indiques que tes fonction instructions_zero n'est pas prévue pour être appelée en dehors du même fichier .f, et le compilo va remplacer le code d'appel de chaque fonction par le contenu de la fonction elle-même.
Sinon, comme dit au dessus, si tu sors le test des boucles, tu devrais gagner un peu aussi.