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 <d...@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@forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull

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

Répondre à