On 07. 02. 18 21:04, Marc Mongenet wrote:
Bonjour
Le 7 février 2018 à 00:22, Daniel Cordey <[email protected]> a écrit :
Sachant que la majorité du code se résume à l'exécution de LOAD & STORE
(mesure sur des millions de lignes de code ayant permit de définir
l'architecture HP-PA, ~80% !!!),
Il doit y avoir un malentendu, car la notion de ligne s'applique au code source,
tandis que la notion LOAD/STORE s'applique aux instructions machine.
Statistiques collectées à l'aide de l'analyse de millions de lignes de
code source de différents langage !
Et il est difficile d'imaginer un programme exécutant 80% de load/store.
Même avec des compilateur d'il y a 25 ans sur une architecture pauvre
en registres comme x86,
:-) Toutefois, c'est cette analyse qui a mené à la création de
l'architecture PA-RISC. PA signifiant justement Precision Architecture
parce que son jeu d'instruction et son architecture avait été pensée sur
la base de cette collecte de statistiques. C'est Joel Birnbaum qui est à
dirigé la conception de PA-RISC, puis par la suite d'Itanium
(magnifiquement mal géré par les équipes marketing d'HP et Intel en
prenant 5 ans de retard dans le dévelopement !). Birnbaum est aussi à la
base du premier processeur RISC chez IBM (IBM 801)...
il n'y a que 34% de load/store dans l'exécution
des benchmarks SPECint92 (ref: Computer Architecture a Quantitative
Approach, 2nd edition, p.81).
Justement le parfait exemple du toy-benchmark débile auquel presque tout
le monde fait référence. Ce qui est dommage est que ces performances ne
se traduisent pas par des comportements aussi magnifique dans les
application générale. SpecInt ne mesure que la capacité à faire toujours
la même boucle et en utilisant un nombre restreint de registres... comme
on ne peut décemment pas se contenter de boucler sur 3 valeurs... on lui
donne un vecteur à manger... qui va utiliser la cache, mais de manière
séquentielle. C'est comme de définir la performance d'un disque en
donnant uniquement ses performances en streaming... la réalité des accès
aléatoire est toute autre. Il en va de même avec les benchmark. Tout ça
pour dire que SPECInt ne permet que de démontrer la capacité d'un CPU a
enchaîné les opération arithmétique sur des entiers. Il faut aussi noter
que depuis 1992 (plus de 25 ans), SPECInt a été complété et est
maintenant composé de plus de benchmarks. Mais ce qui est intéressant
est que :
The SPECint2006 test suite consists of 12 benchmark programs, designed
to test exclusively the integer performance of the system. (wikipedia)
Donc, il est évident que ce genre de benchmark tend justement à
minimiser les LOAD/STORE... Néanmoins, on voit que dans un test purement
conçu pour tester uniquement les performances de l'ALU sur des entiers
on a quand même 34% de LOAD/STORE; je suis d'ailleurs même impressionner
qu'il y en ait autant dans ce genre de tests. Ce qui fait que l'on
imagine bien que dans d'autres tests plus généraux on va se rapprocher
de cette fameuse valeur de 80% :-)
Selon la même source, il y a 20% de branchements conditionnels.
Oui... mais on ne peut pas se contenter de faire une simple règle de
trois pour spéculer sur le gain de performance. Il est indéniable que
les techniques de "branch optimisation" limite la casse, mais leur
impact est souvent moins spectaculaire que ce que l'on pourrait croire.
D'abord on a souvent de nombreux "branch" dans le code, qui sont
imbriqués dans des boucles et le CPU n'a qu'un nombre limité de
registres collectant l'historique des "branch" sur une adresse donnée.
Il y a donc des situation où, de toute façon, on a quand même un branch
miss. Oui, on perd 8-10 cycles (ou même un peu plus) dans ce cas... mais
c'est à mettre en perspective avec les 120-170 cycles qu'il faut à la
dernière génération de CPU-Server d'Intel pour aller récupérer une
donnée dans la cache L3 ! Ce qui fait que, sur un benchmark de web
serveur, l'impact du "branch prediction" fait sourire à côté du reste.
Avec des pipelines d'aujourd'hui de plus de 10 étages,
Le processeur RISC de DEC avait déjà 10 étages à la fin des années 80...
MIPS et SPARC en avait sauf erreur 8, etc. Donc, rien de très nouveau...
supprimer l'exécution
spéculative (correcte dans bien plus de 90% des cas) aurait un effet
dévastateur sur les performances:
... des toy benchmarks.
il y aurait une bulle dans le pipeline
tant que le branchement ne serait pas retiré, donc durant presque
autant de cycles qu'il y a d'étages de pipeline.
Je suis capable d'écrire un benchmark qui va faire un "branch miss" à
chaque boucle en faisant une boucle très courte. Bien sur, j'aurais un
"pipe flush" à chaque coup, mais ma prochaine instruction sera dans la
cache L1... Je connais tout ça depuis... 1986.
dc
_______________________________________________
gull mailing list
[email protected]
http://forum.linux-gull.ch/mailman/listinfo/gull
