Ensuite ce n'est pas au compilateur de se soucier de ça : le processeur gère lui même un cache d'instruction en fonction de la fréquence d'apparition des instructions, et tu ne pourras jamais exécuter le code tout droit, il faut obligatoirement faire les tests de nullitée. Sans compter que de toute façon le processeur évaluera peut être les 2 branches s'il a rien d'autre à foutre (faut bien remplir le pipeline).
Merci. C'est grace a des raisonnements comme ceux la qu'on se retrouve avec du code ultra lent sur Itanium.
Pour info dans le cas de l'Itanium c'est bien le compilateur qui s'en soucie et qui va (tenter d')annoncer au processeur "tiens compte du branchement qui suit".
En plus je comprend rien a ce que tu dis a propos "de la fréquence d'apparition des instructions". Il etablit des statistiques sur les instructions executee dans le passe et il s'en souvient quand il revient dessus? Tu fonctionnes sur quel model? Parce que la tu m'interesses.
[^] # Re: Hmm :/
Posté par mdlh . En réponse au journal Entretient du noyau Linux. Évalué à 1.
Merci. C'est grace a des raisonnements comme ceux la qu'on se retrouve avec du code ultra lent sur Itanium.
Pour info dans le cas de l'Itanium c'est bien le compilateur qui s'en soucie et qui va (tenter d')annoncer au processeur "tiens compte du branchement qui suit".
En plus je comprend rien a ce que tu dis a propos "de la fréquence d'apparition des instructions". Il etablit des statistiques sur les instructions executee dans le passe et il s'en souvient quand il revient dessus? Tu fonctionnes sur quel model? Parce que la tu m'interesses.