[gull] Above Meltdown & Spectre

[Daniel Cordey]

On 07. 02. 18 21:04, Marc Mongenet wrote:
> Bonjour
>
> Le 7 février 2018 à 00:22, Daniel Cordey <dc at pxcluster.com> 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