> Bah me semble qu'il y a des architectures qui cherchent à prédire un branchement en fonction des instructions précédentes
Les processeurs récents contiennent un cache de prédiction, contenant des hash des adresses PC pour les instructions de branchement conditionnel, et pour chaque hash, le résultat précédent du test (sur 1 bit), voire le résultat "moyen" du test (compteur incrémenté / décrementé selon le résultat du test). Ainsi lorsqu'on retrouve l'intruction de branchement on peut choisir la bonne branche. Très utile pour une boucle effectivement : i=0 ; i<100 ; i++ : le résultat du test est le même 99 fois / 100. Notons qu'il peut y avoir une pollution du cache de prédicition si une autre instruction de branchement tombe dans la même case après la fonction de hashage... mais bon c'est mieux que rien.
Je ne pense pas qu'une fonction exécutée "rarement" [exemple de fork() ] n'aille pas en cache. En revanche, elle en sera évincée rapidement, car le code ne sera plus jamais lu.
Il est possible de "dire" au cpu quel est le résultat probable du test : le compilateur connait le processeur pour lequel il compile. Il sait donc, en cas de branchement conditionnel, quelle hypothèse est la plus rapidement exécutée par le cpu. En disant au compilateur qu'une condition est souvent réalisée, il génère le code qui va bien pour que le cpu, sans autre information (cf. branch prediction ci-dessus), prenne la branche la plus probable par défaut (avant d'avoir evalué le résultat du test). Si une condition est rarement réalisée, le compilateur pose test à l 'envers.
[ Note qu'on peut instrumenter le code pour déterminer automatiquement si une condition est souvent ou rarement réalisée, puis recompiler le code à partir de là, pour optimiser le binaire produit ].
Il y a moult publications sur le thème du "branch prediction", c'est important pour les perfos, quoique tu en penses.
Enfin, j'en reviens à mon message précédent auquel tu as répondu je trouve rapidement. Je persiste : si pour tous les tests les bonnes hypothèses sont prises par le cpu, et si le code traitant les branches non exécutées est rejeté "loin" du PC, donc non lu par le chipset de gestion de la ram, il n'y a pas de branchements lointains, et effectivement le cpu peut aller "tout droit", càd avoir toujours un pipeline rempli et des instructions à exécuter.
Je pense qu'on pourrait faire un petit programme de test qui montre les différences de perf en procédant ainsi. Si ça te tente, tiens-nous informé...
[^] # Re: Hmm :/
Posté par Laurent Morel . En réponse au journal Entretient du noyau Linux. Évalué à 1.
Les processeurs récents contiennent un cache de prédiction, contenant des hash des adresses PC pour les instructions de branchement conditionnel, et pour chaque hash, le résultat précédent du test (sur 1 bit), voire le résultat "moyen" du test (compteur incrémenté / décrementé selon le résultat du test). Ainsi lorsqu'on retrouve l'intruction de branchement on peut choisir la bonne branche. Très utile pour une boucle effectivement : i=0 ; i<100 ; i++ : le résultat du test est le même 99 fois / 100. Notons qu'il peut y avoir une pollution du cache de prédicition si une autre instruction de branchement tombe dans la même case après la fonction de hashage... mais bon c'est mieux que rien.
Je ne pense pas qu'une fonction exécutée "rarement" [exemple de fork() ] n'aille pas en cache. En revanche, elle en sera évincée rapidement, car le code ne sera plus jamais lu.
Il est possible de "dire" au cpu quel est le résultat probable du test : le compilateur connait le processeur pour lequel il compile. Il sait donc, en cas de branchement conditionnel, quelle hypothèse est la plus rapidement exécutée par le cpu. En disant au compilateur qu'une condition est souvent réalisée, il génère le code qui va bien pour que le cpu, sans autre information (cf. branch prediction ci-dessus), prenne la branche la plus probable par défaut (avant d'avoir evalué le résultat du test). Si une condition est rarement réalisée, le compilateur pose test à l 'envers.
[ Note qu'on peut instrumenter le code pour déterminer automatiquement si une condition est souvent ou rarement réalisée, puis recompiler le code à partir de là, pour optimiser le binaire produit ].
Il y a moult publications sur le thème du "branch prediction", c'est important pour les perfos, quoique tu en penses.
Enfin, j'en reviens à mon message précédent auquel tu as répondu je trouve rapidement. Je persiste : si pour tous les tests les bonnes hypothèses sont prises par le cpu, et si le code traitant les branches non exécutées est rejeté "loin" du PC, donc non lu par le chipset de gestion de la ram, il n'y a pas de branchements lointains, et effectivement le cpu peut aller "tout droit", càd avoir toujours un pipeline rempli et des instructions à exécuter.
Je pense qu'on pourrait faire un petit programme de test qui montre les différences de perf en procédant ainsi. Si ça te tente, tiens-nous informé...