[gull] Above Meltdown & Spectre

Thu Feb 8 10:09:11 CET 2018

Bonjour,

Est-ce qu’une expertise universitaire indépendante serait utile ?

Faut-il repenser les contrats de licence copyright pour autoriser expressément l’ouverture du code source elle avait fin d’expertise universitaire indépendant ?
Qu’en est-il des processeurs libres si il y en n’a pourriez-vous me donner des liens ?
Ces processeur et sont-ils aussi concernés par ses failles ?

Savez-vous si avec un code simple  en c par exemple avec un pointeur et une boucle  on peut facilement remarquer la faille ?

Merci pour vos renseignements

Salutations

mparchet

> Le 8 févr. 2018 à 02:12, Daniel Cordey <dc at pxcluster.com> a écrit :
> 
>> 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
> 
>    
> 
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull