[gull] Above Meltdown & Spectre

[Daniel Cordey]

On 08. 02. 18 01:23, Marc Mongenet wrote:
> Ne confonds-tu pas les "toy" benchmarks (benchmarks synthétiques)
> que sont Whetstone et Dhrystone avec ce que fait SPEC?

Non... mais j'admets que je les mets dans le même panier. C'est 
peut-être un peu fort depuis que SPECInt est un ensemble de programmes 
différents, mais c'est aussi un peu n'importe quoi... on y mélange 
allégrement gcc et du calcul matriciel... Si je reconnais que l'on a un 
peu quitté le monde des benchmarks de trois lignes, ça ne prouve pas 
grand chose et surtout ne donne pas une vision de ce que ça devrait 
faire vraiment. On ne teste plus les opérations sur les entier (ou long 
c'est selon), mais on est en train de tester plus les caches L1, L2 et 
L3 ainsi que l'ALU... et d'autres choses, y compris des instructions 
spécifiques... Dans SPECInt je m'attendrais à trouver le stress des 
quatre opérations de base sur des entiers de différentes tailles... ben 
non... c'est pas ça.

De toute façon il est stupide de tester des trucs comme Whetstone et 
Dhrystone (et son bout d'assembleur !), mais on continue à tester des 
applications très pointues, gcc, bzip, etc. Ce qui donne... le mix de 
tout ces tests mais ne veut pas dire grand chose. A priori, un benchmark 
devrait donner une indication "utile" (voeux pieux) de performance entre 
les CPUs. Au lieu de ça, on a des processeurs qui ont de meilleurs 
résultats que d'autre qui ont pourtant des fréquences d'horloge 
supérieurs. On teste de plus ne plus la taille des caches et leurs 
modes... mais plus personnes ne sait ce que ces benchmarks mesurent 
vraiment. C'est pour cette raison que j'ai étendu ma définition des "toy 
benhmarks"... ils ne servent à rien... à moins que l'on ne décide de 
monter un serveur qui va passer son temps à compiler du code, ou un 
autre à compresser des fichiers.

Spec a aussi défini des benchmarks pour des bases de données, qui ont 
été largement biaisés par certain fournisseurs de DB avec la complicité 
de constructeurs de serveurs. L'introduction de la notion de ratios avec 
le prix par transaction a donné lieu à une nouvelle compétition du 
meilleur couple de tricheur et à la découverte de nouvelles techniques 
de triche. On te monte une infrastructure de plus de 10 millions, 
consommant l'énergie d'une moitié de centrale nucléaire, ça prend 6 mois 
de travail et on te sort un chiffre... 0.010 centime par transaction... 
le marketing s'en empare et te le placarde partout... en l'estampillant 
SPECM*... A côté de ça la LAMAL paraît vachement honnête !!! Mais le 
sgens retiennent ce chiffre.. et l'associe avec DB, sans se rendre 
compte que ce n'est pas ça du tout... Là dedans tu as un paquet de trucs 
cachés comme du Fiber Channel, des disques SSD haut-de-gamme et une 
batterie de routeur Cisco hors de prix... Donc, qu'est-ce que l'on 
mesure vraiment. Ce qui fait que SPECInt devrait maintenant s'appeler 
SPECPotpourri ou SPEC-gcc-perl-gzip-*
> Bien sûr, à force, les fabricants de CPU peuvent trouver
> des trucs pour optimiser outrageusement certains codes source.
> Ces codes source sont remplacés lorsqu'une nouvelle version des
> benchmarks sort.

Exact, c'était une pratique courante dans les années 80 et 90. C'est 
moins le cas maintenant avec Intel qui occupe une position archi 
dominante sur le marché. EN fait, il n'y a plus vraiment de concurrence, 
d'autant qu'AMD est obligé d'émuler l'archaïque jeu d'instruction du 
x-86... (avec le litte-endian). Il n'y a qu'ARM qui se démarque, mais ce 
n'est pas une architecture très différente...

> Il n'y a rien, ni dans Wikipédia ni ailleurs, qui permet d'avancer
> que ces benchmarks minimisent les LOAD/STORE.

C'est clair personne ne va le claironner, surtout pas les constructeurs 
! De plus, les nouveaux tests ne cherchent pas à minimiser quoique ce 
soit (ou très peu). Ils se contentent de mesurer... quelque chose... (on 
ne sait plus trop quoi d'ailleurs) ce qui permet à tout le monde de 
crier victoire.

J'ai hélas jeté plein de documentations spécifiques à HP-PA et à 
l'optimisation des compilateurs il y a quelques années. Ces infos 
dataient des années 80 et je pensais qu'elle seraient disponibles sur 
Internet, mais je me suis aperçu que 95% a disparu et les infos encore 
disponibles sont entachées d'erreurs. Je t'assure, les statistiques ont 
bien été collectée et je t'assure que nous avons tous été surpris. La 
plupart de tests ont été effectuée sur des codes FORTRAN, C et COBOL; 
l'objectig étant de savoir qu'elle étaient les instructions les plus 
utilisées. ENsuite, les gens d'HP Labs ont déterminé qu'elles opérations 
étaient le splus utilisées. Puis, ils ont décortiqués les opérations 
(collectées sur des système CISC) et ont réfléchit comment émuler les 
opérations complexes avec des instructions simple s'exécutant en un seul 
cycle... après petit compromsi pour savoir quelles commandes on allait 
mettre sur le chip en fonction de l'espace nécessaire à chacune. Ce qui 
a donné un jeu d'instruction très différents des travaux effectués sur 
les processeurs sur les processeurs RISC à Stanford et Berkeley. Le 
pipeline était de 5 et c'était un processeur super bien pensé et c'est 
ce qui le différenciait des processeurs MIPS, SPARC principalement (IBM 
suivait une autre voie).

Il est donc fort dommage que personne n'instrumente l'exécution de code 
sur les processeurs actuels. Mais peut-être qu'Intel n'a pas trop envie 
que l'on découvre qu'ils se moquent du monde en nous vendant du vent 
très cher. Le problème est que ce genre d'instrumentation doit être 
implantée dans le CPU lui-même et que seul le constructeur a les clefs. 
Imagine que tu découvres que les fameux processeurs a 32 cores avec leur 
cache L3 soit une gigantesque arnaque vendue à prix d'or... M'étonnerait 
qu'Intel te donne les clefs pour se faire descendre.

dc