> De même, je m'interroge sur le bénéfice du saut/jump (qui est une rupture
> de contexte puisqu'il introduit une discontinuité dans la séquence des
> instructions) à moins que les processeurs actuels soient en mesure
> d'"anticiper" un saut
C'est un peu plus compliqué, mais en gros c'est ça. Il y a la prédiction de branchements, qui sert a déterminer la probabilité que le 'if()' soit vrai ou pas (mais là n'est pas la question!).
Et le saut direct est déterminé très tôt dans le pipeline. D'autant plus facile a calculer que l'offset est une constante, située pas très loin de l'instruction en cours, et que de toute façon elle est peut-être déjà dans le pipeline, justement, donc on le laisse continuer, et les instructions intermédiaires sont 'simplement' marquées a ne pas exécuter. Du coup, quelques cycles sont perdus dans le pipeline. Genre, 2 ou 4 ? ;-)
Maintenant, je suis pas un pro. J'ai peut-être loupé un truc...
[^] # Re: Traçage et performances
Posté par ymorin . En réponse à la dépêche Sortie de la version 2.6.37 du noyau Linux. Évalué à 4.
> de contexte puisqu'il introduit une discontinuité dans la séquence des
> instructions) à moins que les processeurs actuels soient en mesure
> d'"anticiper" un saut
C'est un peu plus compliqué, mais en gros c'est ça. Il y a la prédiction de branchements, qui sert a déterminer la probabilité que le 'if()' soit vrai ou pas (mais là n'est pas la question!).
Et le saut direct est déterminé très tôt dans le pipeline. D'autant plus facile a calculer que l'offset est une constante, située pas très loin de l'instruction en cours, et que de toute façon elle est peut-être déjà dans le pipeline, justement, donc on le laisse continuer, et les instructions intermédiaires sont 'simplement' marquées a ne pas exécuter. Du coup, quelques cycles sont perdus dans le pipeline. Genre, 2 ou 4 ? ;-)
Maintenant, je suis pas un pro. J'ai peut-être loupé un truc...