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 <[email protected]> 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 > [email protected] > http://forum.linux-gull.ch/mailman/listinfo/gull _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
