On 08. 02. 18 07:05, Dominik Madon wrote:

Le pipeline du Cortex-M15 de l’ARM, par exemple, compte 15 étages et permet 
d’exécuter 3 instructions en parallèle par cycle au maximum. Il peut en théorie 
traiter simultanément jusqu’à 59 instructions à différentes étapes de leur 
exécution. Voici un morceau de code que je viens d’extraire d’un de mes 
programmes en ligne de commande que j’utilise régulièrement (ce n’est _pas_ du 
benchmark):

Merci pour cette analyse très détaillée et intéressante. C'est justement la taille du BHT qui est intéressante. Tout ceci est très efficace pour des pattern que l'on retrouve justement dans des programmes de calcul intensif. Ce qui fait que ces techniques  sont très utiles lorsque l'on fait des boucles, mais a un impact beaucoup plus limité sur des branchements "one shot". L'impact est alors de 50% inférieur à la situation idéale et se trouve noyé dans le reste; ce qui fait qu'à un certain point on ne peux plus "mesurer" l'impact.

On fait des hypothèse sur la base de l'examen du code source. C'est bien mais ça fonctionne rarement comme ça, hélas. Le BHT est utilisé pour d'autres process, de même que les caches (L1 à L3). On peut bien sûr se mettre dans une situation qui va minimiser l'impact des autres process, mais nous sommes sur des machines avec des process systemes qui tournent quoi que l'on fasse. En enlevant un max de process on se remet dans une situation de toy benchmark qui nous permet d'obtenir des valeurs que personne n'arrivera à reproduire en situation réelle.

J'ai fait un jour l'expérience suivante : J'ai écrit un programme (en asembleur) allant lire le registre des clock tick sur un CPU. Puis, dans mon programme C appelant la fonction, j'ai essayé de déterminer l'overhead de cet appel, afin de le soustraire de mes calculs lorsque je voulais mesurer une courte période de temps. A ma grande surprise, en collectant les valeurs, j'ai obtenu de grandes variations  dans mes mesures. Donc, à un moment on est confronté au choix d'utiliser la valeur minimum, ou une valeur moyenne... C'est ce jour là que j'ai véritablement saisi l'impact que les autres process peuvent avoir sur un code même très court. Et encore... je ne faisais pas appel à des valeurs en mémoires (caches), ni de stresse du BHT...

Maintenant... on peut aborder ce que tu dis :

permet d’exécuter 3 instructions en parallèle par cycle au maximum.


C'est justement dans le mot permet que ça devient intéressant. Donc, selon cette théorie, on devrait avoir un CPI de 0.33... Je me trompe où on en est loin ? Je n'ai pas de valeur pour l'ARM, mais les dernières valeurs que j'ai vu passées sont supérieures à 1. Bien que le CPI ne dise pas tout, c'est une indication. De plus, 3 instructions... mais lesquelles ? Tout ceci est fantastique si toutes les instructions ne s'exécute qu'en un seul cycle. Or, beaucoup d'instructions nécessitent bien plus de cycle. Certains mode d'adressage sont d'ailleurs des tueurs dans ce domaine, de même que les opérations de calcul, dont la division est un gros point noir. Alors, que ce passe-t-il dans ce cas dans le CPU ? Le CPU est-il en attente de la fin de toutes les instructions, ou est-il capable de shifter une partie des instructions dans le pipe (j'en doute). Qui plus est, si une instruction fait appel à une valeur qui ne se trouve pas dans la cache L1 ? Là le processeur est en "stall"...

Les techniques que tu décris pour l'ARM ne sont pas nouvelles, car elles sont toutes issues de ce qui a été introduit avec les processeurs RISC dans les années 80. C'est aussi là que l'on s'est rendu compte qu'il y a loin de la théorie à la pratique. Les techniques d'optimisation ont permit de minimiser l'impact des pipe-flush, sans arriver à les éliminer complètement.

La théorie et les hypothèses c'est bien et passionnant, mais c'est lorsque l'on fait véritablement des mesures que l'on se rend compte que certaines choses ne sont pas ce que l'on croit.

dc



        

_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

Répondre à