Le quarante‐septième Top 500 des supercalculateurs mondiaux est sorti en juin 2016.
Rappelons que le Top 500 se base sur une soumission volontaire (de nombreuses machines puissantes mais classifiées, par exemple, ne participent pas à la course) et sur un comparateur de performances spécifique extrêmement parallélisable, le code LINPACK, qui concerne la résolution de systèmes d’équations linéaires.
La deuxième partie de la dépêche revient sur ce classement et aborde une partie des commentaires de la page d’annonce.
Du nouveau en tête de classement !
Lors de la dépêche précédente, l’année 2015 se finissait sur une sempiternelle victoire de Tianhe-2. Il aura donc fallu attendre cette année pour qu’il soit (enfin) détrôné par Sunway TaihuLight, qui monte à 93 pétaFLOPS. On remarquera d’ailleurs que si ce dernier triple le nombre de cœurs pour tripler la performance, il est annoncé pour une consommation moindre que son prédécesseur : 15,4 MW contre 17,8 MW. Le podium est complété par Titan, un ancien numéro 1 du classement.
L’évolution par pays
La Chine détient toujours la première place du classement et continue sa croissance (passage de 109 à 167 entrées dans le classement, devenant premier en utilisation et en capacité de calcul).
Les États‐Unis continuent leur descente dans le (ou partage du) classement, passant de 199 à 165 supercalculateurs, soit de nouveau la valeur la plus basse depuis le début du Top 500.
Si le Royaume‐Uni sortait immédiatement de l’Union Européenne (et non dans deux ans), le Brexit ferait perdre à l’UE douze systèmes, l’Allemagne en ayant 26 et la France 18 (machines ayant été soumises à ce classement).
L’évolution par fabricant
Cray Inc. compte cinq supercalculateurs parmi les dix premiers. Pour le nombre, HPE est toujours dominant puisqu’il est le constructeur de 127 machines, mais son pourcentage est en baisse (25,4 %). Le Chinois Lenovo réalise une formidable progression avec 84 machines. Cray suit avec 60, puis IBM avec 38 et Bull avec 22.
À noter que tous les supercalculateurs en France sont fabriqués par Bull (principalement pour Météo France et le Commissariat à l’Énergie Atomique) à l’exception notable de celui de Total (SGI) et celui du CNRS (IBM). Parmi les gros supercalculateurs, le constructeur français équipe aussi le Centre de Données pour le Climat allemand.
Les processeurs Intel dominent largement le classement, puisqu’ils équipent 455 systèmes, soit 91 % de l’ensemble (en hausse). Les processeurs POWER d’IBM suivent, puis ceux d’AMD.
Les systèmes d’exploitation
Il y a 497 systèmes sur les 500 sous GNU/Linux, UNIX reste présent sur trois (AIX), les Windows ont disparu du paysage.
Ainsi la famille Linux égalise le record porté par la famille Unix en 1998, marquant la fin de l'âge d'or de cette famille dans le classement.
Une deuxième vie pour les supercalculateurs
Cet article indique qu’en mars 2016, EDF a fourni un supercalculateur datant de fin 2010 à l’UPMC. À l’époque de sa mise en place, il était 37e au Top 500, gageons que ce « don » permettra à l’Université Pierre et Marie Curie / Paris VI de former au mieux les futurs ingénieurs français (et sans doute l’utiliser pour leurs chercheurs). La puissance d’un supercalculateur comme Ivanoe permet de modéliser plus finement les phénomènes physiques pour mieux les comprendre. Les comportements peuvent être abordés à des échelles très variées. Les études peuvent coupler différents domaines : thermodynamique, mécanique des structures, mécanique des fluides, etc. Les approches probabilistes permettent en outre de maximiser la qualité des simulations.
Petite comparaison des classements
| Nom | Top 500 | Graph500 | Green500 (nov. 2015) | GreenGraph500 (nov. 2015) |
|---|---|---|---|---|
| Sunway TaihuLight | 1 | 2 | N/A | N/A |
| Tianhe-2 | 2 | 7 | 90 | ? |
| Titan | 3 | ? | 63 | ? |
| Sequoia | 4 | 3 | 55 | 21 |
| K Computer | 5 | 1 | 214 | ? |
| Mira | 6 | 4 | 56 | 19 |
| Trinity | 7 | ? | 143 | ? |
| Piz Daint | 8 | ? | 20 | ? |
| Hazel Hen | 9 | ? | 127 | ? |
| Shaheen II | 10 | ? | 80 | ? |
Aller plus loin
- Top 500 : le site (1318 clics)
- Top 500 : la liste de juin 2016 (937 clics)
- Top 500 : les principales nouveautés de juin 2016 (221 clics)
- Green500 : classement des machines du Top 500 selon leur efficacité énergétique (189 clics)
- DLFP : Le Top 500 des supercalculateurs de novembre 2015 (300 clics)
- DLFP : le tag « top500 » (127 clics)
- Graph500 : classement des machines selon leurs capacités en simulation physique 3D (179 clics)
- Green Graph500 : classement des machines du Graph 500 selon leur efficacité énergétique (145 clics)
# Bizarre le cadeau d'EDF...
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Le cadeau d'EDF est un peu empoisonné. Avec la consommation électrique de ce cluster, en quelques mois il se paye quelque chose de plus puissant à base de GPU… Sauf si EDF offre aussi l'électricité…
[^] # Re: Bizarre le cadeau d'EDF...
Posté par lockidor . Évalué à 10.
Certes, mais les GPU ne sont pas la panacée non plus ; à partir du moment où les calculs à effectuer ne sont pas facilement décomposables en calculs matriciels, des CPU classiques seront largement plus efficaces, voire même la seule solution exploitable.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Dfg . Évalué à 4.
Cette remarque n'est plus vraie depuis un certain temps.
Les GPUs ne font pas que des calculs matriciels, ils font n'importe quel calcul. Ce qui est vrai, c'est qu'ils ne fonctionnent bien qu'avec des problèmes très massivement parallèles et peuvent être limités par la bande passante du PCI Express entre le CPU et le GPU, donc parfois difficile à nourrir.
Mais la plupart des calculs scientifiques font des opérations mathématiques en parallèle sur des grilles en N dimensions, ce qui est parfaitement adapté à du calcul sur GPU.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par lasher . Évalué à 10.
Les GPU sont très utiles dans beaucoup de cas, mais tout dépend du type de données que tu manipules. S'il y a beaucoup d'indirections par exemple, le GPU n'aura sans doute pas l'opportunité de tirer avantage de motifs d'accès à la mémoire qui lui seront favorables (en gros : si l'accès à la mémoire GPU est « unitaire » alors le GPU a du matériel qui permet l'accélération des accès; sinon, l'accès se fera mais beaucoup plus lentement).
Il y a aussi le problème des tests. Certes, dans un code scientifique on a tendance à limiter les branchements autant que possible, mais certains types de calculs requièrent l'utilisation fréquente de branchements difficile à prédire en général (par exemple : les codes de compression, qui sont souvent utilisés avant de transmettre les données via le réseau ou pour les stocker sur disque).
Enfin, il y a tout un tas d'applications qui manipulent un volume de données important (sans pour autant être du type « big data »), mais les objets qui sont manipulés et transformés sont parfois très petits individuellement, c'est-à-dire qu'il y a de gros tableaux n-dimensionnels, mais aussi de petites matrices (genre 20×20, 30×30, etc.), qu'il est difficile à agréger. Du coup, s'il est possible de changer le code pour accommoder le GPU, ça requiert un effort significatif, qui peut être jugé comme trop important (car après il faut passer tous les tests de régression, etc.).
[^] # Re: Bizarre le cadeau d'EDF...
Posté par freejeff . Évalué à 8.
Pour compléter ce que dit lasher, un cluster comme celui d'EDF n'est pas qu'une puissance de calcul c'est aussi un moyen d'accéder à des librairies au travers de Codes dédiés. Si on prend l'exemple de EDF, ils ont logiciel libre de calcul éléments finis qui s'appelle Code_Aster et qui s'appuie sur tout un tas de librairies pour pouvoir conduire le calcul sur un super-calculateur. Dans le cas des éléments finis, effet on a une matrice à résoudre mais à la fin elle peut très bien être de taille 10e6x10e6, ce qui devient assez complexe à envoyer sur un GPU mais également sur un calculateur, il faut donc découper le problème, pour que chaque sous problème rentre sur un noeud, cela se fait avec parametis, ensuite résoudre les problèmes locaux, cela peut être fait avec PetSC dans certains cas, ensuite comme les différents problèmes sont couplés, il faut donc recoller et faire des aller retours entre la solution locale et la globale. Il y a un domaine de recherche qui ne s'occupe que de ça. Par exemple PetSC est depuis peu capable de farie du GPU computing sur CUDA mais ce n'est qu'expérimental et peu recommandé. Il est donc impossible de passer comme cela sur du GPU. De plus ce code est aussi utilisé chez EDF pour valider les conceptions des centrales nucléaires, il vaut donc mieux éviter de faire n'importe quoi et d'avoir des régressions, ils se doivent donc d'être parfois conservateurs sur les technos utilisées. Les architectures sous linux ayant des compilateurs C/C++/fortran ont encore de beaux jours devant eux ! Et là je ne parle que de logiciels libres, je ne parle même pas des codes propriétaires, qu'il est extrêmement complexe de faire fonctionner sur du matériel non standards …
[^] # Re: Bizarre le cadeau d'EDF...
Posté par n0wic . Évalué à -10.
Qu'EDF est bête, s'ils étaient malins ils auraient utilisé Javascript et Node pour stocker des datas dans le Dom pour partager tout ça, ne dit on pas que la plus part des utilisateurs Lambdas utilisent moins de 10% de leurs puissance de calcul (bureautique) ? Pourquoi en plus d'exploiter les ressources de la planête n'utiliseraient on pas cette puissance de calcul gaspillée pour faire du calcul et aussi du stockage en passant ?
D'ailleur c'est déjà la politique d'EDF d'acheter la surproduction d'éléctricité des particulier alors pourquoi pas : je ne crois pas que javascript soit payant qui plus est la legislation est très neuve et permissive en la matière.
Et dans tous les cas l'alime tourne au même régime non ? Dites le moi si je me trompe.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par freejeff . Évalué à 9.
Je ne comprends pas bien ce que tu dis mais en fait sur ce genre de problèmes les langages interprétés sont rarement utilisés. On parle de systèmes mis en place pour traiter des problèmes dont la taille ne passe pas du tout en mémoire donc Dom, javascript et consort ne sont pas trop en mesure de gérer ces cas. Sur ce genre de bestiole, il n'y a pas de puissance perdue, il y a des queues et les gens soumettent des jobs qui vont être mis en attente puis executés en fonction d'une politique données dépendant de ton investissement dans les machines le nombres de processeurs, le nombre de noeuds et la taille de la mémoire. Ce n'est pas fait en vain.
Après EDF n'est pas bête, je pense que ça fait partie des entreprises qui ont encore beaucoup de gens très compétents …
Il me semble que tu ne connais visiblement pas assez le domaine du calcul intensif pour emmètre un avis pertinent !
[^] # Re: Bizarre le cadeau d'EDF...
Posté par n0wic . Évalué à -10. Dernière modification le 07 juillet 2016 à 17:29.
Effectivement je ne suis pas qualifié dans le domaine des grid computers et de la résolution des problèmes de Mathématiques compliqués, cela n'a dit cela n'empèche en rien la formulation de multiples hypothèses simples et la métaphorisation adapté de rigueur Mathématique à défaut de ne pas avoir une rigueur Mathématique scientifique.
D'ailleur en parlant des gens compétents qui travaillent chez EDF je me demande comment on fait pour faire le choix d'un paradigme dans le cas d'un travail commun, le chef est il celui qui maitrise la plannification du déploiement du cluster ou celui qui maitrise les opérations binaires et les machines de Turing ? (qui sont des notions abordées dès la 1ère année d'enseignement technologique)
Ou bien est celui qui est capable de les décrire à un niveau humain en adéquation à sa discipline.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par barmic . Évalué à 5.
Ce dont tu parle existe déjà, mais ne s'applique pas à n'importe quel calcul.
D'une part (et cocorico !), il y a les grid5000 qui est une grille de calcul géré par l'enseignement supérieur monté sur des petites machines réparties un peu partout en France.
D'autre part tu as les projets comme Boinc qui sont des plateformes que tout le monde peu installer chez soit pour aider les projets qui l'utilisent en leur donnant du temps de calcul. Les problématiques sont assez spécifiques :
Mais c'est intéressant et déjà très utile. Je crois qu'on avait entendu parlé ici d'un projet pour faire ça en JS pour que les utilisateurs n'aient même pas à installer de client (mais je en retrouve pas).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bizarre le cadeau d'EDF...
Posté par ckyl . Évalué à 4.
Je suis pas sur que ta définition de grid5000 soit très pertinente ni en lien vers avec ce dont il parlait. C'est "juste" un ensemble de clusters repartis dans la France et reliés via liens dédiés à haut débit.
Grosso modo, ca correspond à ce que tu ferais chez n'importe quel iaas. Interco tres rapide au sein d'un meme clusters (bon la tu vas avoir des trucs bien plus rapide que du 10GB type infiniband), interco rapide au sein d'un même site geographique et tu dis bonjour à la vitesse de la lumière pour passer d'un site à l'autre même si la France est petite… C'est juste plus typé calcul scientifique qu'un iaas (batch scheduler etc.)
Il parlait je pense d'une idée veille comme le monde, et surtout les années 2000, de voler du cycle cpu inutilisés chez les gens ou stations de travail pour faire tourner les calculs. Il suffit d'aller voir tout les trucs qui ont foirés ou vivotes pour comprendre les limites du truc.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par barmic . Évalué à 3.
C'est pour ça que je parlais de BOINC
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bizarre le cadeau d'EDF...
Posté par BAud (site web personnel) . Évalué à 3.
tiré d'un dossier de presse :
j'imagine que la refacturation de l'utilisation financera le coût électrique, peut-être déjà pris en compte au titre du partenariat EDF / UPMC (je n'ai pas d'info spécifiquement dessus…).
Puis bon, 510.00 kW (chiffre issu de la fiche du top500), c'est à peine 1000 fois plus qu'une alim' d'un gamer : tous ceux qui jouent à LoL, WoW sont bien plus dépensiers^Wconsommateurs :-) C'est à peine plus qu'1/2 millième d'une ancienne tranche nucléaire (900 MW iirc).
Pour mon info, comme je suis une burne en calcul de consommation, par an cela correspond à combien en conso / facturation ? (kW je comprends, kWh un peu, kVA beaucoup moins…).
En se basant par exemple sur les tarifs d'énergie renouvelable : https://particulier.edf.fr/content/dam/2-Actifs/Documents/Offres/Grille_de_prix_L'offre%20renouvelable_20160101.pdf qui indique ~15 € du kWh ?
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
DE mémoire, j'aurais tendance à dire qu'une consommation continu de 1W, coute 1€ à la fin de l'année. Mais je me trompe sans doute.
"La première sécurité est la liberté"
[^] # Re: Bizarre le cadeau d'EDF...
Posté par KiKouN . Évalué à 1.
J'ai le même raisonnement. Après, prévoir un peu plus avec l'évolution du prix. Mais c'est un moyen simple de faire connaître le prix de la consomation d'un appareil surtout en veille. Cette égalité 1W = 1€ a un petit effet choc pour cela.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'avais aussi en tête le cout des veilles ou le cout d'un frigo de 100W à 100€ dans l'année.
"La première sécurité est la liberté"
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Yth (Mastodon) . Évalué à 7.
Option de base à 15,37c€ le kWh, ça fait :
* 15,37/100/1000 €/Wh ;
* 15,37*24*365.25/100000 €/Wan
-> 1 Watt pendant un an coûte 1€347.
Les tarifs ont augmentés par rapport à vos souvenirs !
Si on fait un calcul avec heures creuses et pleines, sachant qu'il y a 8 heures creuses et 16 heures pleines, avec une consommation de 1W permanent, donc sans optimiser les heures :
(16,62*16+11,89*8)*365.25/100000 €/Wan
-> 1 Watt pendant un an coûte 1€319
A priori l'utilisation heures creuses/pleines est un poil plus rentable pour un serveur branché 24/24, mais ça change pas grand chose…
Sans compter l'abonnement bien sûr, mais comme il faut le répartir sur la consommation totale, on n'a pas assez d'information pour le prendre en compte :)
Ici en mode basique pour le super-calculateur à 510kW, ça ferait à l'année :
510000*(15,37*24*365.25/100000) = 687k€ annuels !
Je suppose que la machine consomme plus quand elle travaille effectivement que quand elle ne fait rien, si il n'y a aucun calcul ça doit baisser, donc on a ici un maximum, au tarif particuliers, qui n'est très certainement pas le tarif UPMC (mais j'avoue n'avoir aucune idée de ce qu'ils peuvent avoir comme tarif).
Ça fait quand même une sacrée blinde…
Yth.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par rpnpif . Évalué à 1.
Si cette pointe à 510 kW n'arrive qu'une fois par mois pendant dix minutes et que la puissance moyenne est de 1 kW, cela fait beaucoup moins. En fait cette puissance de 510 kW ne dit rien du tout de la consommation.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par lockidor . Évalué à 3.
Si c'est le cas, c'est tout de même dommage d'avoir un supercalcu pour qu'il glandouille pendant tout le reste du temps :/
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Yth (Mastodon) . Évalué à 3.
Ouais, c'est pas comme un four à la maison ce genre de machines, je pense qu'on essaie de les faire travailler au maximum. D'où la revente à des PME, labos et autres.
Donc le calcul donne un coût maximum en électricité, et un ordre d'idée du coût réel.
On sait qu'on va parler en k€/an.
Comme quoi la pointe à 510kW donne quand même quelques infos générales…
Yth.
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
J'imagine que cette puissance ne tient pas compte de la clim, non plus…
"La première sécurité est la liberté"
[^] # Re: Bizarre le cadeau d'EDF...
Posté par rpnpif . Évalué à 3.
Un kWh c'est 15 centimes d'euros pas 15 €. :)
[^] # Re: Bizarre le cadeau d'EDF...
Posté par rpnpif . Évalué à 1.
Un kWh c'est 15 centimes d'euros pas 15 €. :)
510 kW ne veut rien dire sur la consommation. Est-ce la consommation de pointe comme ce que l'on indique en général ou la consommation permanente (très rarement indiquée).
Une quantité d'énergie consommée se calcule en joules ou traditionnellement pour l'électricité en kilowatt-heures. Un kWh est la quantité d'énergie consommée (par exemple) d'un appareil utilisant une puissance d'un kW pendant une heure (ou bien 0,5 kW pendant 2h, etc.).
# Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 10. Dernière modification le 24 août 2019 à 14:33.
Ce nouveau venu est étonnant sur plusieurs points, et présage d'une évolution différentes des serveurs, et c'est pas rien.
Le Sunway/shenway Taihulight utilise des processeurs maisons chinois RISC fait maison, dans certains anciens modèles semblaient inspirés ou compatibles avec le jeu d'instruction DEC Alpha. Donc, les Intel/AMD ne sont plus utilisés dans l'ordinateur le plus puissant, et ça risque de se développer de plus en plus (voir plus bas).
Les chercheurs qui travaille sur cet ordinateur ont plusieurs projets très intéressant pour donner un coup de fouet au code vieillissant. Pour rappel, les bibliothèques d'analyse numérique (beaucoup en fortran, pas mal en c/c++) sont généralement open source (OpenMP, OpenACC and MPI, etc…), comme les mathématiques (quelques millénaires avant GNU/Linux), ce qui permet à tout le monde d'ajouter son grain, à la connaissance et au calcul et à réutiliser. Le problème dans certaines parties, est qu'ils ont plusieurs décennies cumulées de patch sans trop de réorganisation, et plus personne n'y comprend rien. Pour les réseaux neuronaux par exemple, la partie apprentissage n'est pas vraiment scalable (adaptable à un grand nombre de processeur), les performances sont donc médiocre. Les chercheurs ont décidé de remettre ça au propre en même temps qu'ils portent sur cet ordinateur à 10 millions de cœurs (pour rappel le second Tianhe2 a 3 millions de cœurs). Les tests préliminaire avec les changements n'ont utilisé que 8 millions de cœur mais sont déjà prometteurs sur les gains de performance.
Ils vont également essayer de mettre un peu au propre les algorithmes de météorologie qui sont aussi un peu défraîchis.
Inside Look at Key Applications on China’s New Top Supercomputer
Concernant le processeur, RISC et fait maison, des changements s'annonce, Intel est, avec le Tianhe-2, à la seconde position, complètement largué, le 3e et suivants étant encore loin derrière le Tianhe-2 qui est lui même loin derrière le 1er en terme de performances, mais 2 autres mauvaises nouvelles se profil pour le x86 dans le monde des supercalculateurs :
Le résumé et les liens donnés ici sont intéressants à ce sujet : ARMv8 64-bit Processors To Replace Intel Xeon and SPARC64 Processors in Some Supercomputers
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Il y a un truc que je ne comprend pas : Intel nous "impose" toujours ce vieux CISC alors qu'en interne "tout est RISC", du coup ça fait de la perte de puissance à cause de cette conversion permanente, alors qu'une tonne de serveurs ont que des logiciels libres (LAMP etc) compilable pour toute architecture et où beaucoup de choses sont parallélisables. Mais pourquoi donc on n'a pas de concurrent qui propose une puce compétitive face à un Xeon 10 cœurs par exemple?
ARM dans les serveurs, ça doit faire 10 ans que c'est annoncé (et avant, dans les années 2000 c'était PowerPC qui allait tuer Intel), mais en pratique rien de compétitif (et les boites ayant misé dessus se sont cassée la gueule); est-ce que ce genre de nouveau CPU peut un jour concurrencer Intel sur des "petits serveurs à base d'OS open source"?
Je serai curieux d'avoir un SW26010 et voir ses perfs ainsi que le prix d'une machine "mono-CPU"… Et si en bonus ça peut botter les fesses d'Intel qui s'endort sur ses lauriers depuis qu'il a tué AMD (qui fait que le a figuration depuis des années tellement ses CPU sont décevants de nos jours)…
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par reno . Évalué à 3.
Sérieux tu pose réellement la question? Pour la même raison que les RISCs haute performance (Alpha et autre) sont morts: Intel peut vendre ses x86 dans le monde Windows ET dans le monde Linux alors qu'un NEW-Alpha sera confiné au monde Linux, donc le retour sur investissement est beaucoup plus difficile --> Intel a les meilleurs fab.
Certes Intel a un désavantage: le jeu d'instruction x86 qui nécessite un décodeur complexe et ça a été probablement un gros désavantage quand les transistors étaient "rare et cher" mais maintenant que le problème principal est "quoi faire avec tout ces transistors?" le désavantage est réduit..
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui et tu n'y as pas répondu.
Le marché desktop se réduit et pas les mêmes CPU (Core-M contre Xeon), de plus en plus de serveurs tournent sur du Linux et de l'open source, ARM a aussi le marché smartphone pour le R&D sur la conso, ça commence à faire.
euh… vu le nombre de serveurs qui bouffent quelques pourcents de l'énergie mondiale, désolé mais on sait quoi faire des transistors, justement.
Bref, désolé mais tu ne me convaincs pas.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Kerro . Évalué à 3.
Je trouve que si.
Le prix d'un Xeon CISC moyen de gamme produit en « grande série » est probablement moins élevé que celui d'un CISC de même puissance brute qui n'est produit qu'en minuscule série.
Pourquoi en minuscule série ? Pour la simple raison que presque personne n'en achète. Tu en as déjà acheté toi ? Tu connais une entreprise qui en a acheté ? Moi non plus. Et si tu voulais en acheter pour monter par exemple une ferme de 30 serveurs (ce n'est pas n'importe qui déjà), tu les trouverais où ?
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 6.
Ben, justement, comme je disais, les premiers produits ARM 64bits sont arrivés l'année dernière enfin, fin 2014 plus précisément, le temps que la stack linaro se stabilise et que tout le monde s'y mette à pris du temp. 2015 est resté relativement confidentiel côté serveurs et SBC (quelques rares modèles), moins côté mobile (phone/tablette) où ça a été l'explosion. cette année, ça commence à être moins confidentiel côté serveur avec les marques sus-cités, presque une dizaine de serveurs chez Gigabyte par exemple, avec des Soc moyens, mais en mezzanine (petite carte contenant le Soc), donc upgradable.
Depuis cette année on trouve des ARM 64 bits avec suffisamment de cœurs (48 ou 64) et de puissance pour équivaloir aux Xeon en calcul brut, avec toujours le ratio puissance/énergie beaucoup plus intéressant des RISC. Quelques hébergeurs se sont hasardé à des offres low cost sur des SBC 32 bits depuis 2 ans, je ne sais pas trop si ce marché à attiré du monde; On voit que les SBC 64bits, tout en gardant des prix abordables (<100€) se multiplient cette année (à peu près tout le monde en fait, sauf des marques genre TI complètement larguées). Toutes les distros ont des version ARM, et ça marche déjà très très bien pour le bureau (à l'exception des pilotes fermés GPU/vidéo : limite du driver GPU fermé si ARM Mali, début de pilotes dans la branche principale Mesa pour Broadcommm et depuis plus longtemps les Snapdragon de Qualcomm). Il faut donc mixer fermé/ouvert pour le bureau ou ne pas avoir d'accélération 3d (avec toujours le problème OpenGL vs OpenGL ES (merci Vulkan de résoudre ça, il faut maintenant attendre que les applications soient adaptées).
Côté serveur, du moins applis internet les plus courantes, on s'en branle complètement du pilote 3d/vidéo. Tout est dispo et fonctionne parfaitement sur ce genre d'architecture. Qemu/KVM & Xen fonctionnent aussi, Linaro à fait un papier sur l'état de l'art, qui semble dire que les générations de SoC de l'année dernières était un peu justes, celle de cette années sont appropriées :
On the Performance of ARM Virtualization
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Antoine . Évalué à 5.
Un petit détour par la réalité ne serait pas du luxe :
http://www.anandtech.com/show/10353/investigating-cavium-thunderx-48-arm-cores
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 1.
Le thunderX est la précédente génération, avec, notamment, les défauts décrits par Linaro, concernant la virtualisation, il est sorti en 2014…
La deuxième génération, ThunderX2 54 cœurs à 3 Ghz, comble beaucoup de lacunes de la première.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 2.
Comme le fait remarquer l'article dans la page de la comparaison avec les autres ARM. Le ThunderX (version 1) à une puissance par core à peu près équivalente aux Cortex-A57, que l'on trouve dans les téléphones mobiles moyen de gamme de l'année dernière et il y a deux ans. C'est la première gamme d'ARM 64 vits. On est loin de la puissance des Cortex-a72 haut de gamme (que l'on trouve également dans des processeurs à bas prix comme certains Mediatek ou Samsung), qui commencera a être remplacé dans les produits par les Cortex-A73 en 2017. HiSilicon (filiale de Huawei) propose aussi des 64 cœurs Cortex-A57@2.1GHz, pour son premier SoC à destination des serveurs. Leur premier Soc ARMv7 (K3V2, 4*Cortex-A9 32 bits) est sorti en 2012, ça donne idée de la vitesse d'évolution et d'adaptation dans l’écosystème ARM.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Antoine . Évalué à 7.
Ton ThunderX2 est disponible où ? On ne peut pas tester un processeur qui n'est pas sorti.
Si tu veux t'intéresser aux processeurs ARM pas encore sortis, le minimum de l'honnêteté serait de les comparer avec des processeurs Intel pas encore sortis non plus.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 1.
Effectivement, il était annoncé, en mai, devait être présenté, en juin au salon « ISC High Performance conference » (ISC-HPC, à Frankfurt, en Allemagne), mais je n'ai trouvé que peu d'informations sur cet événement, dont rien sur le ThunderX2, EEtimes annonce sa sortie pour la fin de 2017 (« won’t be in volume production until late next year »).
1 an et demi semble très long pour la sortie d'un SoC ARM en grande quantité (pas de produits les utilisant), chez les concurrent, il y a généralement 3 ou 4 mois entre l'annonce et la sortie de produits pour les clients finaux. Si ils continuent dans cette direction, il est clair qu'ils vont se faire distancer par les différents concurrents également en train de se préparer activement sur le marché.
Visiblement, le X-Gene1 d'AppliedMicro (qui est vendu par Gigabytes) en carte mère seulement, à de meilleures performances par cœur que le thunderX (1ere version du moins), il se positionne plus vers les serveurs contenant des petits Xeons au niveau perfs/caractéristiques de la carte mère et proc/prix.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela n'a rien à voir avec le RISC, et c'est même plutôt faux à cause de la densité du code moins importante.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par reno . Évalué à 1.
Je ne suis pas tout à fait d'accord: ajouter un décodeur x86 dans le CPU et sous utiliser le CPU car le compilateur ne peut voir qu'un petit nombre de registre, ça a aussi des conséquences au niveau de la consommation.
Et pour ce qui est de la densité de code moins importante des RISC, tu retardes: ARM et MIPS ont tout les deux des extensions avec instruction 16 bits, qui ont une densité de code équivalente à celle des x86, ce qui permet d'avoir le "meilleur des mondes" pour ces RISCs: du code compact pour le "tout venant" mais quand même accès a beaucoup de registre/des instructions supplémentaire quand il y a besoin.
Après il est vrai qu'ARMv8 n'a pas cette extension ce que je trouve très surprenant.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Ce n'est pas faux, mais beaucoup moins vrai depuis le mode 64 bits qui double les registres. De plus, le système superscalaire offre de fait des centaines de registres invisibles.
Je ne retardes pas du tout. Thumb était loin de l'efficacité des x86, très loin même. Il n'offrait même pas toutes les possibilités du jeu 32 bits (ce qui imposait d'utiliser plusieurs instructions 16 bit ou repasser en 32). Thumb2 propose un mode mixte 32/16, j'imagine que tous les nouveau cpu ARM utilise se mode de base. Mais cela reste moins optimal que le code x86, il suffit de comparer la taille des binaires générés.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par reno . Évalué à 3.
De mémoire une comparaison entre Thumb2 et x86 avait trouvé Thumb2 légèrement + dense que le x86, c'était peut-être légèrement moins dense mais
1) ça se tenait dans un mouchoir de poche.
2) le x86-64 est moins dense que le x86 (sauf pour faire des calculs 64 bits évidemment).
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il faut voir si la comparaison était faite avec "gcc -O2", "gcc -OS" ou "gcc -O3" qui prend forcément plus de place.
Pour le 2), c'est forcément le cas, puisque les registres supplémentaires sont obtenu avec un prefix. Mais d'un autre coté, avoir plus de registres permet souvent de se passer d'accès à la mémoire.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Renault (site web personnel) . Évalué à 4.
Déjà la proposition initiale me semble mensonger :
Il ne faut pas oublier que le 2e du classement est sorti en 2013 avec des Intel qui ont au moins 2 générations de retard par rapport à ceux d'aujourd'hui.
La performance des chinois reste impressionnant, mais on ne compare pas non plus ces processeurs maison avec les derniers Intel ce qui biaise le résultat.
Intel a déjà tenté de faire autre chose que du x86 avec Itanium et vue la réussite commerciale, on peut comprendre qu'ils ne s'aventurent pas trop dans ce genre d'expérimentations.
De plus, le passage CISC -> RISC n'est pas si coûteux que tu ne le crois, surtout qu'aujourd'hui Intel a tellement de transistors dans une puce qu'ils ne savent littéralement pas quoi en faire (ajout monstrueux de mémoire cache, ajout de cœurs, ajouts d'instructions fantaisistes, etc.). S'il est possible de gagner légèrement en performance là dessus, cela n'est clairement pas suffisant pour mériter un changement d'infrastructure.
Intel malgré tout maitrise le x86 et a des performances excellentes. Même sur la question énergétique ils ont grandement comblé le retard.
Pour qu'une autre architecture gagne, il faut des sous et des fabs à la hauteur de l'enjeu. ARM a bien percé en 10 ans (même si Intel est loin d'en mourir) et cela a favorisé la renaissance de la portabilité dans l'industrie logicielle ce qui à terme pourrait favoriser l'émergence d'une autre architecture.
Si le gouvernement chinois met beaucoup de moyens, il se pourrait bien que le x86 et ARM soient concurrencées sérieusement.
Je ne trouve pas qu'Intel s'endorme tant que cela sur leurs lauriers. Il y a eu beaucoup de progrès sur la consommation énergétique et la performance du GPU. Il devient difficile pour eux de faire mieux.
Là où ils s'endorment est je dirais du côté commercial, l'abandon du processeur Atom en est d'ailleurs la preuve de cet échec.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 2.
Concernant les supercalculateurs et Intel, toujours est il que personne ne semble vouloir concevoir de supercalculateurs plus puissant avec des Intel, le 3e, fait par cray n'est même pas à la moitié de la puissance de Tianhe-2 et à environ 1/5e de la puissance du Sunway. Personne d'autre n'a fait un ordi de la puissance du Tianhe-2 en Intel et son augmentation de puissance va se faire avec du RISC, la consommation électrique et l'investissement initial des intel est telle que personne ne peut se permettre d'investir dans un calculateur de cette puissance, pour ne pas avoir le budget pour le faire tourner ensuite… Ne nous leurrons pas les évolutions des Intel d'une génération à une autre < 30% d'augmentation de puissance, donc, l'impact est faible au vu de la différence de résultat. Et comme le rappelle les articles du Top500, la puissance éléctrique nécessaire pour faire tourner le TaihuHilight, est bien inférieure, à puissance équivalente, à ces concurrents, malgré une architecture relativement rudimentaire (DDR3 plutôt que DDR4, bus plus lents (qui ne l'empêche pas de battre les autres sur des utilisations pratiques), et devrait entrer dans le green 500 sans trop de problèmes.
Intel casse les prix sur les basse conso (Atom), lourdement concurrencés par des SoC ARM à 5$/10$, par contre, sur les SoC serveurs, les évolutions sont très lente et les prix astronomiques. Ils ont profité de quelques années pour bien marger et faire des réserves financières. Laisser continuer cela, c'est se tirer une balle dans le pied pour nous autres utilisateurs. C'est en train de changer dans ce domaine :).
On est plus à l'époque du PowerPC avec un Linux un peu jeune, et pas tout l'écosystème opensource d'aujourd'hui. L'open source bouffe à peu près tous les marchés à présent (entre Github, les serveurs, supercalculateurs, modems, routeurs, embarqué, machines outils amateurs, téléphonie, etc…), avec une grande portabilité, à l'époque du PowerPC, il y avait en gros Mac et gros systèmes IBM sur Power, et Windows, OS/2 sur Intel. Silicongraphics (MIPS), Sun (SPARC) et Digital moribond (Alpha), tous propriétaires et incompatibles sur les serveurs, et un début de Linux avec quelques rares applications mais sur toutes les archis, c'était le milieu des années 1990, apache n'avait pas 10% des parts de marchés face à NCSA et quelques autres serveurs HTTP propriétaires.
Idéalement, l'ouverture / portage du code nous rend service, Des projets fabless de processeurs Opensource commençaient il y a 2 ou 3 ans, je ne sais pas où ils en sont aujourd'hui, mais on peut espérer une percée légère de ces archis, au même titre que les rasbpi dans un premier temps, pour avoir des objets à bidouille ou sécurisés sans contraintes fermées (pas d'Intel ME par exemple).
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . Évalué à 10.
Je réinsiste, mais encore une fois, je pense que t'es a côté de la plaque dans des interpretations. C'est pas un problème de Intel vs ARM (ou CISC vs RISC), c'est un problème de CPU versus GPU (ou proco manycore). Les trois premiers calculateurs ont tous des GPU/manycore: SW26010, Xeon Phi ou Nvidia Tesla. Les GPU (ou manycore) offrent 5-10 fois plus de performance à consommation équivalente par rapport au processeurs multicore classiques, mais uniquement sur des workload très parallèles (et sans branchements, et sans accès aléatoire à de la mémoire). Les GPU ont pas mal révolutionné le monde du HPC: aujourd'hui personne n'entraine des réseaux de neurones sans GPU. Les GPU sont devenu l'outil d'exécution standard pour une partie des workload scientifiques. Donc encore une fois, le monde des processeurs n'est pas divisé entre CISC/RISC mais entre CPU/GPU.
Ensuite, c'est une erreur de tirer des conclusion générales sur la performance d'un processeur. Oui le SW26010 marche très bien pour faire du calcul scientifique, mais pour faire tourner nginx + RoR + PostgreSQL, il sera problablement très mauvais (oui plus mauvais qu'un bon vieux Xeon). Ça n'a pas vraiment de sens de parler de la performance "en général" d'un processeur. Un processeur est bon ou mauvais sur une workload donnée. S'il s'agit de multiplier des matrices, le SW26010 sera très bon, il va bénéficier de toutes les unités SIMD qu'on a fourré sur le chip. S'il s'agit d'exécuter ta page RoR et que la base données a besoin d'aller chercher des trucs partout dans la mémoire, mieux vaut un Xeon avec son gros pipeline, son caché énorme, et ses 3 controlleurs mémoire par cœur qui vont permettre d'extraire de l'IPC.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 3.
Je crois qu'il y a eu des confusions dans les interprétations de ce que j'ai écrit. Déjà l'évidence des 'GPU' ou 'DPS' pour la supériorité de calcul matriciel ne date pas d'aujourd'hui, ça me parait complément débile de mettre ça en avant sans comprendre les architectures tant c'est fondamental. Cela à tendance à prouvé que vous avez lu l'article en diagonal, ce que n'ont pas fait les rédacteur de Top500, lisez tous les articles à ce sujet s'il vous plaît, ils ont bien insisté sur les réelles avancées proposées et concrétisées par les développeurs/intégrateurs.
Je parlais d'une part d'une Sunway, en tant que processeur de calcul (il a 64 unités "GPGPU" (pour les simpliste) par cœur processeur. Nvidia, qui domine le marché des GPGPU suit la même direction sur ses processeurs ARM sentant un gros marché.
Pour faire simpliste dans le même acabit RISC au niveau CPU pourrait être comparé à KISS au niveau système.
À aucun moment il n'a été évoqué, la vocation du processeur Sunway pour l’exécution de nginx… ? Je parlais des processeurs RISC en général, et des actuelles évolution de l'écosystème ARM au niveau des serveurs, qui est à la fois un problème différent car ce ne sont pas les mêmes besoins au niveau de l'architecture, ni marchés, et liées, car dépendant de systèmes moins cloisonnés (GNU/Linux est aussi dominant sur ce marché).
Le marché, utilisant des systèmes libres bien entendu, alternatif des processeurs ARM64bits est balbutiant (moins de 2 ans, comparés à plus d'une décennie pour les x86) mais déjà très prometteur. Si tous les distributions (Linux/BSD/etc), constructeurs s'y mettent, et ont déjà beaucoup de clients, ça n'est probablement pas pour perdre du temps/argent… Il suffit de comparer les prix à l'achat, benchs, et consommation de ce qui existe.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Non, c'est complètement faux. Ce n'était vraiment pour les tout premiers modèles, ou le décodeurs étaient ultra simpliste : bit de contrôle de l'alu ou du controleur mémoire + adresse de registre. Avec les techno superscalaire, c'est devenu beaucoup plus compliqué. Si le décodeurs x86 est toujours aussi complexe, il l'est autant qu'à l'époque des pentiums.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Je crois revenir 15 ans en arrière. Cette phrase ne veut rien dire. RISC ou cisc qualifie un jeu d'instruction, dire que tout est "RISC derrière" n'a aucun sens.
Non au contraire, la densité de code est énorme en x86, l'itanium devait avoir des Mega octet de cache pour battre un x86. Et il est mort.
Il te faut qq milliard pour ça. Et il faut avoir le logiciel optimisé qui va avec. Les piles complètes logiciels sous Linux, ne sont pas si vieilles que ça.
AMD annonce une nouvelle architecture 30% plus rapide en monocore pour une même fréquence. Faut-il encore qu'il la sorte rapidement.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 1.
Le port aARM64 de GCC/LLVM est à la fois récent et ancien, ça permet déjà de beaux bench/core/énergie, dans pas mal de SoCs…
Si les logiciels sont libres/ouverts pas de problème de portage (sinon, bugreport, et patchs, ça prend généralement quelques minutes à faire et quelques jours max à approuver (testé)) et quelques mois pour arriver dans les distros. Mais il faut vraiment un test tordu spécifique x86 pour que ça arrive :).
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par David Mouton (site web personnel) . Évalué à 4.
Force est de constater que le processeur chinois semble très puissant et le mystère qui entoure son architecture encourage toutes les spéculations.
Cependant on peut aussi relativiser.
Le Sunway/shenway Taihulight aligne en gros 3x plus de coeurs pour 3x plus de puissance. Ce qui fait des coeurs aussi puissant que les intels de 2013.
Aujourd'hui, un Xeon E7-8890 v4 dispose de 24 coeurs fonctionnant à 2.2 GHz / 3.4 GHz en charge classique et 1.8 / 3.4 GHz en charge AVX.
Un Xeon Phi de génération Knights Landing offre jusqu'à 72 coeurs de type Silvermont associés par paire, partageant un cache L2 de 1 Mo et gérant chacun deux grosses unités vectorielles AVX-512.
En tout cas voilà une nouvelle qui devrait relancer la compétition avec Intel, et c'est bon pour l'innovation.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . Évalué à 5.
Il y a quand même quelques éléments qui ont fuité, et qui expliquent pas mal la perf obtenue. Voir par exemple
Report on the Sunway TaihuLight System, par Jack Dongarra.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 2.
Le processeur de Sunway ne doit pas dater d'hier non plus, il y a toujours un délai entre le premier processeur sorti d'usine, la production, la conception de l'architecture, la fabrication de ses cartes, le choix de son emplacement, sa construction et sa finalisation. Si la machine est annoncé au TOP500 juin 2016, elle a probablement déjà fait l'objet de tests et applications et ne doit pas non plus dater de juin 2016, etc… c'est aussi pour ça qu'il n'y aura pas encore de supercalculateur avec les derniers d'intel avant 2018. Il est aussi très probable que cette année Shunway ai produit de nouvelle génération de processeurs étant donné l'investissement de l'état. Ici c'était régional, pour des applications pratiques (météo, infrastructures et urbanisme) et l'évolution du logiciel commun à toute la planète, visiblement plein de nœuds à démêler :).
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . Évalué à 10.
Tu as raison de faire remarquer l'architecture très particulière de ce nouveau super calculateur; c'est la première fois qu'on voit calculateur n'incluant aucun processeurs connu: Intel Xeon, IBM Power ou Sparc. Par contre, tu sembles (en tous cas, c'est mon interprétation) en tirer la conclusion d'une victoire du RISC sur le CISC, et par extention des architectures historiquement RISC (e.g. ARM) sur les architectures historiquement CISC (e.g. x86).
Ça me semble être une erreur parce que la distinction RISC/CISC a de moins en moins de sens. Les processeurs Intel actuels (typiquement labelés CISC) découpent les instructions en micro-opérations (notés µops) élémentaires qu'ils exécutent ensuite. Inversement, les processeurs ARM ont maintenant des instructions qu'on pourrait qualifier de complexes (e.g. instructions SIMD qui opèrent sur des vecteurs). Aujourd'hui, on appelle CISC les jeux d'instructions qui distinguent les opérations mémoires des opérations arithmétiques. Par exemple, les processeurs Intel (CISC) offrent une instruction ADD qui peut prendre une opérande en mémoire. En interne, le processeur exécute une instruction de chargement mémoire, suivie d'une addtion entre deux registrees. Sur un processeur ARM (RISC), il faut d'abord . En fait, de nos jours, la différence entre un processeur CISC et un processeur RISC est assez minime, et surtout n'a que peu d'impact sur la performance du processeur. D'autres facteurs influencent plus la performance comme la taille du pipeline d'exécution, la taille et la configuration des caches, la fréquence, et la répartition des unités de calculs.
J'ai l'impression qu'on peut distinguer trois grandes familles de "processeurs" (je note processeurs entre guillemets car certains "processeurs" commencent à ne plus ressembler beaucoup à l'idée qu'on se fait d'un processeur).
Depuis quelques années, les supercalculateur tirent le gros de leur puissance de calcul soient de processeurs manycore, soit de GPU. Ce type de processeur offre de meilleurs performances que les multicores sur des workload très parallèles, mais moins bonnes sur des workload plus séquentielles. En général, les workload HPC sont bien parallélisables (le en général est quand même à prendre avec des pincettes). Du coup, les manycore ou GPU sont avantagés parce qu'il n'y a pas de silicium "gaché" pour avoir une performance séquentielle élevée (long pipeline, unité redondantes, cache inutilement gros). À ce titre, le Sunway TaihuLight n'est pas si étonnant et entérine juste le fait que les manycore et GPU sont avantageux en HPC. Par contre, c'est quand même la première fois qu'on voit un supercalculateur sans aucun processeur multicore.
La Chine entérine aussi sa supériorité technologique naissante, avec non seulement les deux premiers calculateurs du TOP500, mais aussi avec un processeur de conception maison.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à 0.
Je ne suis pas totalement d'acord avec cette interprétation RISC/CISC. Le jeu d'instruction reste plus simple sur les RISC que sur les CISC aujourd'hui et le fait d'utiliser des instructions complexes consomment toujours plus d'énergie en étant toujours moins optimal. Est-ce que les compilateurs d'aujourd'hui sont capable de penser en terme énergétique.
Le SIMD est une unité de calcul spécialisée au sein du FPU, il est plus typiquement RISC dans sa conception, ses instruction les plus utilisées muladd est une instruction simple dans sa conception mais très parallélisée. Elle est fondamentale dans tout calcul vectoriel/matriciel, le fondement de l'analyse numérique. On en trouvait déjà sur les architecture Power et autres dans les années 1990. Des instructions de type sinus et cosinus au sein des FPU sont par contre totalement CISC, on en trouve pas dans les fonctions des processeurs RISC, mais bien sur les Intel x86, sur les 68K etc. ce type de fonction est calculé, en analyse numérique par développement limité, ce qui revient encore une fois à faire des muladd. On se charge en général de l'optimiser en amont au niveau de l'algorithme, donc, son implémentation matérielle à peu d’intérêt (microcode, plus de câblages inutiles, redondance du code, moins optimal au final).
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
C'est complètement faux. Les instructions très spécialisé sont bien plus efficace : instruction AES par exemple, ou simplement les instructions SIMD à 4 opérandes…
Cela ne sert à rien. Un code plus efficace dans le sens classique est aussi un code qui consomme moins.
Cela ne veut rien dire en terme d'architecture. J'imagine que tu veux dire qu'une unité SIMD classique n'a pas les instructions x87 typique comme sin ou cos, et j'imagine que tu veux dire qu'il y a moins de microcode, mais le microcode est géré avant l'unité de calcul.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . Évalué à 3.
En fait je crois qu'on peut dire que ça dépend. Effectivement pour AES-NI, les implémentations hardware sont très efficaces. Pour d'autres instructions, type VGATHER, j'ai déjà eu des pertes de performance en comparaison à l'utilisation d'un ensemble d'instructions plus simples. Pareil dans certains cas, pour faire un pop count, les instructions SIMD "simples" sont plus efficaces que l'instruction "complexe" POPCNT microcodée (SSE3: fast popcount). Mais dans l'ensemble, je suis plutot d'accord avec toi, les instructions "qui font le café" microcodées sont souvent très efficaces.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par tao popus . Évalué à -1.
AES, utilise généralement un cœur spécialisé chiffrement, encore une fois on tombe sur ce que je comparais au KISS, quand je parlais des ARM. Ce type d'opération n'est pas inclus dans les processeurs principaux, ça n'aurait aucun intérêt et d'éventuels SoC qui n'auraient aucune volonté à faire de chiffrement.
Ces fonctions sont complètement indépendante du code général, aucun intérêt de les mélanger, elle ont plutôt une fonction de traitement sur un flux de donnée que sur une seule variable ou registre… Il en va de même du DSP (traitement audio/vidéo), des contrôleurs de périphériques, etc…, qui sont cependant dans les SoC, tous au sein de la même puce pour raccourcir les échanges (moins de passage par le circuit imprimé, infiniment plus lent) et réduire par la même consommation/surface utilisée.
Comme je disais plus haut (peut être revoir l'historique pour la collision chronologie), les instructions SIMD à n opérandes sont complètement dans la philosophie RISC, on les trouve depuis des années, la philosophie du RISC, consiste à avoir des instructions simple et les pipeliner au maximum, ce qui est le cas des fonctions muladd (mulsub, etc..) des SIMD. on en trouve dans les processeur RISC depuis au moins 20 ans.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . Évalué à 10.
Non. Sur les processeurs Intel, les instructions AES-NI ne sont ni exécutées par un coprocesseur, ni par un core dedié. Elles sont exécutées comme n'importe qu'elle autre instruction. En particulier, elles utilisent les registres SIMD (1) (donc pas de registres spécifiques), elles sont décodées et pipelinées exactement comme toutes les autres instructions, et sont dispatchées sur les ports d'éxecution du processeur (2). En fait, tout laisse à penser qu'elles ont été implémentées dans l'ALU SIMD, comme n'importe quelle autre instruction SIMD.
(1) Voir Intel Manual Volume 2A, Instruction Set Reference, page AESENC
(2) Voir Agner Fog, Instruction Tables, page(s) AESENC.
Honnêtement, je vois pas trop ce que les instructions SIMD des processeurs Intel récents (genre AVX) ont de RISC (ou de simple). Elles sont probablement parmi les plus complexes à décoder: le schéma de codage (VEX) supporte entre 2 et 4 opérandes, des registres de 128 bit ou 256 bit (3). Au passage les opérandes peuvent parfois être en mémoire, parfois dans des registres. Une partie de ces instructions est microcodée, et certaines font le café…
Et malgré le fait qu'elles soient complexes, ces instructions permettent souvent des gros gains de performance.
(3) Voir Intel Manual Volume 2A, Instruction Set Reference, section 2.3 Intel Advanced Vector Extensions
Le problème est que tu manipules un concept tellement flou "la philosophie RISC" qu'on arrive pas à discuter. Tu nous dit que le philosophie RISC, c'est: un core simple, des instructions simple, et du KISS. On a montré que que RISC != core simple. Aujourd'hui le décodage d'instruction CISC, ça consomme que dalle en silicium comparé aux caches, pipeline et autre. Après, "instruction simple", ça ne veut rien dire. C'est quoi une instruction simple ? c'est une instruction pas microcodée ? c'est une instruction qui ne fait qu'une seule opération ? La seule chose qu'on peut dire c'est que RISC, c'est Reduced Instruction Set Computing, dont ça suppose un jeu d'instruction réduit, donc peu d'instructions, donc que des instructions généralistes. La multiplication actuelle des instructions SIMD, des plus en plus spécifiques, c'est pas très RISC parce que ça augmente la taille du jeu d'instruction. Pareil, le concept de "KISS", y'a rien de plus flou.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Je confirme que sur les SoC Arm tout est sous forme de core externe, ce qui impose tout un tas de contraintes chiantes :
- L'usage du core n'a aucun intérêt sur les petits paquets en terme de perf (à cause du temps de setup)
- Il n'y a jamais tous les mode (CBC, XTX,…)
- Le support de l'OS est obligatoire
- L'usage par plusieurs applications est compliquée
Bref, la mode des cores à ajouter autour des ARM n'est pas top. Le seul avantage est de pouvoir couper leur alimentation quand on s'en sert pas… (Donc, l'avantage est de ne pas s'en servir…)
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par oinkoink_daotter . Évalué à 4.
Je ne sais pas ce qu'il en est sur les cœurs crypto ARM dans le détail (la page kikipedia parlant aussi des rondes), mais dans le cadre AES-NI chez Intel, les instructions ne couvrent que le calcul des rondes AES. C'est à toi de fader la gestion des modes, et les XOR et autres manip perverses avec les IV.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Quand tu fais un core tu es obligé de faire les modes avec, sinon les aller-retour sont trop coûteux en temps. Autant tout faire avec le cpu.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par X345 . Évalué à 7.
Si tu as une référence relativement récente (c'est à dire qui date pas de 1995 avec des processeurs gravés en 250nm) sur la consommation d'énergie des architectures CISC vs RISC, je suis intéressé. Intel arrive à faire des processeurs avec un TDP très faible (voir par exemple, List of Intel Atom processors), qui pourtant supportent tout un tas d'instructions CISC à la FCOS ou FSIN.
En fait, j'ai l'impression qu'aujourd'hui, le fait qu'un core soit RISC ou CISC a peu d'impact sur sa performance, et sur sa consommation énergétique. Dans les années 1990, un core RISC était un core simple (= consommant peu de silicium), et un core CISC était un core complexe (= consommant beaucoup de silicium). C'était du au fait que le core CISC utilisait du silicium pour implémenter des instructions complexes à la FCOS. Depuis ce temps, on a gagné un facteur 10 en finesse de gravure (dans les années 90, on faisait du 250nm, maintenant on est vers 25nm). Aujourd'hui implémenter les instructions CISC consomme une quantité de silicium négligeable. D'autres facteurs, comme la taille et la configuration des caches, la taille du pipeline, ou le nombre d'unités redondantes vont avoir plus d'impact sur la consommation de silicium et consommation d'énergie que le fait d'être RISC ou CISC. Il y a moins de différence (en terme de conso. énergie et silicium) entre un core d'IBM Power7 et un core de Intel Xeon (deux processeurs multicore, l'un RISC et l'autre CISC) qu'entre un core de Intel Xeon et un core de Intel Xeon Phi (un processeur multicore, un manycore, les deux CISC). Sur un processeur moderne, les caches utilisent une grosse partie du silicium (voire par exemple, Haswell-E processor features, 6e slide, Intel Core 5960X Processor Die Map), pas l'implémentation des instructions CISC.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
De nos jours ce qui occupe le plus de silicium, c'est tout le système superscalar pour pouvoir lancer en parallèle l’exécution de plusieurs instructions. C'est quadradic avec le nombre d'étage de pipeline, le nombre d'unité de calcul, et la taille de la fenêtre d'instruction utilisée.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Maxime Ritter (site web personnel) . Évalué à 5.
En fait la philosophie CISC, c'est toujours plus d'instructions (complexes), pour toujours plus de performances. Et pour faciliter la tâche du programmeur.
La philosophie RISC, c'est beaucoup moins d'instructions, mais des instructions qui consommment peu de cycles. Tant pis s'il faut faire 6 instructions pour faire ce qu'on peut faire avec un seul en CISC (de toute façon on a arrêté de coder en ASM, ya des compilos pour ça), on s'y retrouve parce que ces instructions consomment moins de cycle.
Ca c'est la théorie RISC vs CISC au début des années 90. Une époque où ceux qui codaient pouvaient encore coder le nombre de cycles consommés, et où les concepteurs de CPU étaient plutôt bridés par le nombre de transistors à leur disposition dans un CPU/coeur.
La pratique en 2016 c'est que presque toutes les instructions consomment un cycle, voire une partie de cycle, on a assez de transistors pour cela. Donc on fait quoi ? On rajoute à nouveau des instructions : MMX, SSE (SIMD), AES… Alors CISC vs RISC, moi je rigole : ça n'existe plus.
Après il est vrai qu'Intel part avec le l'handicap de continuer à maintenir une compatibilité de ses processeurs avec les gammes précédantes, et que ça remonte loin dans le temps… Du coup, ça marche bien avec windows et un univers de sources fermés.
Dans un univers de sources ouvertes ou il suffit de recompiler avec un compilateur adapté, tu peux avoir un set d'instruction qui reflète mieux l'organisation interne de ton CPU, et avoir au final une meilleure efficacité de ton CPU (et utilisation énergétique). D'où la percée des ARMs sur téléphones.
Mais plus on intègre de transistors, moins ce sera handicapant de garder cette compatibilité : un décodeur devant (dont la consomation en transitors est faible), et voilà (d'où Intel tente aujourd'hui même de faire de l'embarqué basse consommation, où ils étaient tellement mauvais dans le temps qu'ils n'y allaient même pas).
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par lasher . Évalué à 5.
Ça c'est faux. Les instructions vectorielles (AltiVec pour PowerPC, MMX/SSE/AVX pour x86) durent effectivement moins d'un cycle lorsque le pipeline est plein (donc en termes de « débit »). Mais la latence d'une instruction, fut-elle vectorielle, dure bien plus qu'un cycle.
De même, les instructions x86 scalaires de type « arithmétique avec opérandes à la fois en registre et en mémoire » nécessitent par définition plus d'un cycle pour s'exécuter, en particulier si on parle de divisions, modulo, ou opération flottantes.
Un jeu d'instruction RISC sépare explicitement les accès mémoire du reste : toutes les opérations arithmétiques se font registre à registre, là où les autres jeux d'instructions proposaient des systèmes plus ou moins complexes (calcul par accumulation, par pile, registre-mémoire, mémoire-mémoire, etc.; le x86 mélange tout ça).
La raison derrière le succès de RISC (et la raison pour laquelle Intel utilise un système de micro-opérations—AMD ne faisait [fait?] pas ça avec ses instructions x86 pour les premiers Athlon & Opteron), c'est justement qu'en réduisant le jeu d'instruction, et en le simplifiant,
a = b + c * d, sur des machines x86 d'il y a 6 ans, il aurait fallu générer une multiplication et une addition séparément; sur les processeurs x86 récents, on peut utiliser une opération de Fused Multiply-Add (FMA) qui va se charger de tout. On y gagne en nombre d'instructions (une de moins) et en performance.Le principe de CISC, c'était de faire des instructions complexes qui utilisaient des registres cachés pour aller plus vite (et aussi gagner en espace mémoire). RISC, c'était un concept qui simplifiait le jeu d'instruction, demandait d'avoir beaucoup de registres adressables, et se reposait sur les progrès en théorie de la compilation pour correctement exploiter le pipeline (qui n'existait pas sur x86 avant le 486, et n'a commencé à être efficace qu'à partir du Pentium).
Je l'ai déjà dit ailleurs, un x86 (au moins chez Intel) aujourd'hui se comporte comme un RISC dès qu'on a passé le front-end (partie récupération d'instruction et décodage), vu que (1) toutes les instructions sont décomposées en micro-instructions, et (2) on est passé de ~8 registres adressables du Pentium 1 (32 bits) à 32 (16 « généraux » et 16 « vectoriels » mais qui peuvent être utilisés comme des vecteurs scalaires), comme les processeurs RISC classiques, sur les architectures 64 bits actuelles.
En attendant, le front-end du pipeline d'Intel reste limité, et la raison pour laquelle les instructions prennent en moyenne 1-2 cycles en termes de débit (hors accès mémoire), c'est qu'il y a en interne un cache de micro-instructions (à noter que le PowerPC/POWER d'IBM a un truc similaire, et pourtant le jeu d'instruction est bien plus proche de RISC que le x86).
Oui et non : si ça reflète trop le comportement interne de ton processeur, alors il y a un vrai risque que le programmeur qui aurait besoin d'écrire de l'assembleur ait vraiment plus de mal à écrire son programme. La conception d'ISA doit être relativement fidèle à ce que fait le processeur, mais aussi doit permettre au concepteur de compilateur et au programmeur bas-niveau de pouvoir raisonner sur un modèle machine suffisamment complet mais aussi suffisamment simple. Exemple à la con : j'ai bossé (en tant que « programmeur ») sur une archi expérimentale qui faisait explicitement la différence entre nombres flottants et entiers (jusque là, pourquoi pas, ce ne serait pas la première fois), mais aussi entre les pointeurs « lointains » et « proches » (mémoire scratchpad locale ou de niveau supérieur, ce qui en soit n'est pas non plus complètement nouveau, ça se faisait avant aussi), et où il n'y avait aucun caches, donc tous les mouvements mémoire devaient être explicites. Franchement, écrire un compilateur optimisant pour ce truc, c'est dur.
Plus tard, lorsque l'architecture a été simplifiée du point de vue du logiciel, nous avions toujours besoin d'effectuer les mouvements mémoire manuellement, mais au moins le matériel avait intégré un système permettant de détecter la « distance » pour une opération mémoire (c'est important, vu que la raison première pour cette distinction était l'économie d'énergie: un accès « proche » pouvait ne demander que 16 bits, un accès moyen 32 bits, et un accès lointain ou absolu, 64 bits d'adresse).
Je passe sur tous les trucs et astuces qui existent pour sauter des étages, transmettre des résultats d'opérations à d'autres étages avant de les avoir effectivement écrits en mémoire/registre, etc. ↩
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Une ISA qui reflète trop le fonctionnement interne du CPU a un autre problème: ça devient compliqué d'implémenter la même ISA avec une architecture interne différente. Et quand on voit la durée de vie de l'ISA du x86, ou encore plus longue du jeu d'instruction du 8051 de chez Intel, il vaut mieux faire un truc qui laisse un peu de liberté du côté du design du CPU.
# Mono-culture
Posté par Ermaion (site web personnel) . Évalué à 2.
Suis-je le seul à m’inquiéter de la monoculture Linux ?
Que Microsoft soit définitivement éliminé, je ne m’en plaindrais pas mais que les BSD soit complètement absents du classement m’étonne toujours. Ce sont de très bons OS et DragonflyBSD me paraîtrait même être le choix évident.
[^] # Re: Mono-culture
Posté par Zenitram (site web personnel) . Évalué à 7.
Pourquoi mutualiser les efforts serait inquiétant? C'est libre, et donc tout le monde peut changer ce qui ne convient pas.
Que Linux soit "la monoculture" montre surtout que la gestion du projet est bonne, en étant assez polyvalent pour que les gens n'aient pas besoin de prendre autre chose.
Peut-être que le pluriel dans cette phrase est un début d'explication.
Je te retourne la question : qu'apporterait un xBSD de plus qu'un Linux qui fasse qu'on ne prenne pas la "mainstream"?
[^] # Re: Mono-culture
Posté par nokomprendo (site web personnel) . Évalué à -1.
On pourrait dire la même chose de windows pour le desktop alors ?
Et concernant la "bonne gestion" qui rend linux tellement adapté au HPC, tout le monde ne semble pas de cet avis : http://www.ece.ubc.ca/%7Esasha/papers/eurosys16-final29.pdf
[^] # Re: Mono-culture
Posté par Zenitram (site web personnel) . Évalué à 6.
N'en déplaise à ceux qui veulent faire l'autruche, oui avec réserve (l'impossibilité de forker, donc la coût de concurrence est élevé ce que n'a pas Linux car logiciel libre)
Si ils savent mieux que les autres, ils peuvent proposer leur version du scheduleur et tout le monde se jettera dessus et même qu'il pourrait être dans la version upstream.
Si ils ne le font pas, peut-être que c'est juste de beaux théoriciens à la critique facile sans risquer de montrer qu'on peut mieux faire.
Faut-il vraiment que je donne ici les avantage du libre?
[^] # Re: Mono-culture
Posté par Renault (site web personnel) . Évalué à 3.
Sans compter que rien n'indique quel scheduler est utilisé dans ces machines hors normes, probables qu'ils utilisent des solutions maisons.
Sans oublier également que ces machines exécutent des tâches qui n'ont rien à voir avec ceux d'un ordinateur personnel, et de fait qui peuvent mieux exploiter le scheduler natif par exemple.
[^] # Re: Mono-culture
Posté par BAud (site web personnel) . Évalué à 2.
oui, cela me semblerait important pour justifier que toutes les VM sont sous Debian plutôt que sous RHEL :-)
cela va te prendre une 60aine de page :/
Seul Oracle a été de promouvoir le libre en entreprise, grâce à leurs conditions tarifaires débiles sur les plateformes de virtualisation hébergeant soit une base (PostgreSQL étant une alternative bien plus pérenne), soit un serveur d'application (Tomcat ou Jboss étant bien souvent bien suffisants et efficaces). Je puis élaborer, mais je veux bien ton interprétation :-)
[^] # Re: Mono-culture
Posté par lasher . Évalué à 2.
C'est surtout que même si tu as un chouette patch à proposer pour le noyau, s'il n'est pas adopté et que tu es « tout seul » (pas de soutien de la part de structures plus ou moins grosses), alors ça ne vaut pas le coup de le maintenir, vu qu'il faudra courir après toutes les modifs effectuées sur les versions suivantes du noyau et que tu n'auras sans doute pas beaucoup d'aide pour maintenir ton code.
Je n'ai plus tous les détails en tête, mais lorsqu'il s'était s'agit de refondre le code pour les threads Linux, il y avait une certaine compétition entre l'implémentation actuellement utilisée par le noyau, et la bibliothèque proposée par IBM. Il y a sans doute une certaine rancœur et une certaine jalousie, mais j'en connais qui disent que la bibliothèque d'IBM était supérieure mais avait le défaut de ne pas avoir été codée par un pote de Linus (notons que tout ça n'est que commérage—mon premier paragraphe est celui qui a du « contenu » :-) ).
[^] # Re: Mono-culture
Posté par nokomprendo (site web personnel) . Évalué à 1.
https://github.com/jplozi/wastedcores
[^] # Re: Mono-culture
Posté par Renault (site web personnel) . Évalué à 6.
Les *BSD n'ont de mémoire jamais dépassé sérieusement la dizaine d'unités.
Déjà, on constatera qu'une part de l'attrait de Linux dans le secteur provient de l'aspect commercial avec des éditeurs pour en assurer le support, gérer le développements et qui ont probablement une expertise dans le secteur. C'est le cas pour entre un quart et un tiers des machines ce qui n'est pas négligeable.
L'autre raison est sans doute historique, la même raison qui fait que Linux a globalement détrôné *BSD partout. Notamment l'incertitude concernant la viabilité juridique du projet.
Et une fois que Linux a commencé à décoller dans le secteur, cela fait une boule de neige : plus d'expertise humains et logiciels autour, code adapté à ce cas d'usage, développement de distributions commerciales, etc.
# fabricants
Posté par ekaia . Évalué à 0.
À noter que tous les supercalculateurs en France sont fabriqués par Bull
Il y a beaucoup de clusters en France qui ne sont pas des clusters Bull. Ce n'est pas le seul constructeur à vendre en France : IBM (Lenovo), HPE, SGI, Dell, …
[^] # Re: fabricants
Posté par BAud (site web personnel) . Évalué à 0.
tu as été moinssé car manque de liens :/
liens ? (le catalogue de C-S peut t'aider pour Bull et Dell), pas forcément sur hpc où ibm décliné par bull m'est connu mais où il y a peut-être plus d'intervenants non visibles ?
[^] # Re: fabricants
Posté par Jiel (site web personnel) . Évalué à 3.
Non, moinssé car l'article parle des systèmes, des supercalculateurs, des processeurs… du Top 500. Il s'agit évidemment de tous les supercalculateurs qui sont dans le Top 500.
[^] # Re: fabricants
Posté par ekaia . Évalué à 3.
Sur https://www.top500.org/statistics/sublist/ filtrer par pays: France
"18 entries found" dont 6 :
11: Total Exploration Production, SGI
81: CNRS/IDRIS-GENCI, IBM
141: EDF R&D, IBM
219: Airbus, HPE
223: EDF R&D, IBM
384: EDF R&D. IBM
Ça fait seulement un 66% pour Bull ;)
[^] # Re: fabricants
Posté par Kerro . Évalué à 2.
La phrase originale est :
notable = il y a d'autres exceptions
Donc la phrase n'est pas fausse. Mais elle n'est pas franchement vraie non plus :-)
On pinaille là.
[^] # Re: fabricants
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
À noter que tous les supercalculateurs soumis au classement du TOP500 pour la France sont assemblés par Bull.
Là d'accord.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: fabricants
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 1.
Une partie des machines d'Equip@méso pourrait encore être classées en 5ème page du top. Et il ya eu de tout dans les fournisseurs : IBM, Dell, HP, SGI, Bull…
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: fabricants
Posté par Brice Goglin . Évalué à 6.
Le #11 Pangea de Total ne compte pas ? C'est un SGI et il est en France…
[^] # Re: fabricants
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
Tu as tout à fait raison.
(J'ai pas regardé la liste, je suis vexé, ils ne veulent toujours pas ajouter une sixième page au top :o)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Orthographe
Posté par Gabbro . Évalué à 5.
Bonjour,
l'UPMC.
[^] # Re: Orthographe
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Ou est-ce que je me plante ?
Posté par domble42 . Évalué à 2.
Bonjour,
Je suis pas du tout bon en hardware, j'aimerai que quelqu'un m'explique ou je fail dans le raisonnement (pcq manifestement, je fail quelques pars).
un rpi 0 c'est 24 GFlops (GPU) pour 0.7 Watt.
Pour rentrer dans le top 10 du classement il nous faut 72,352 GFlops pour 2,834 Kw
ça fais 3015 Pi 0 (pour 2.110 Kw)
Donc pour 15 000$ (5$ le pi 0) je peux créer un super calculateur qui rentre dans le top 10 des super calculateur du monde en consommant moins d’énergie ?
[^] # Re: Ou est-ce que je me plante ?
Posté par KiKouN . Évalué à 2.
Il y a pas mal de raison:
[^] # Re: Ou est-ce que je me plante ?
Posté par Rémi PALANCHER (site web personnel) . Évalué à 3.
Tu te trompes d'échelle. Le top10 c'est 7,235 Pflops soit 7,2 millions de GFlops.
Considérant que les 24Gflops du GPU RPI soit en double précision (ce dont je doute), il faudrait 301459 RPI pour atteindre un Rpeak équivalent. Ça change la facture : 1,5M$ et 0,2MW hors stockage et réseau.
Et on parle de Rpeak là. Le top500 se fait sur le résultat du Linpack. Je connais pas les perfs des compilos sur le GPU RPI, mais étant donné les perfs réseau des framboises, ça m'étonnerait que tu puisse atteindre les 1% d'efficacité sur 300K boards :) Soit 72Tflops, et bien loin de la 500ème place…
[^] # Re: Ou est-ce que je me plante ?
Posté par domble42 . Évalué à 1.
bonjour,
J'ai donc fait une erreur de 10 lors de la conversion, honte a moi.
En fait les chiffres sont tellement grand que c'est complexe pour moi de me faire une représentation de la puissance de calcul de ces super calculateur. L’idée est de convertir ça en multiple de chose que je connais: une grappe de raspberry pi, ou encore de carte graphique dernière gen.
Autre question, a quoi peut bien servir une telle force de calcul ?
Dans le domaine de la crypto pour casser des clés, dans le domaine de la physique appliquée (simuler des phénomènes physique), et quoi d'autre ?
[^] # Re: Ou est-ce que je me plante ?
Posté par Renault (site web personnel) . Évalué à 8.
C'est quand même un gros morceau. Dedans tu as des calculs pour la mécanique des fluides pour concevoir les avions, bateaux ou voitures de compétitions… Cela inclus aussi la prévision météorologique.
Tu as les calculs de balistiques, pour les armées, les simulations du nucléaires pour arrêter les tests réels de ces armes.
Tu as probablement des calculs de structure en architecture pour s'assurer que le bâtiment résiste à toutes les conditions.
En géologie c'est utilisée par exemple Total pour déterminer si les études sur une zone pourrait donner du pétrole ou pas.
Tu as certaines machines comme le LHC au CERN qui génèrent une quantité astronomique de données à traiter. Un supercalculateur peut être nécessaire pour exploiter cela.
Sans oublier la recherche fondamentale qui peut en avoir besoin, notamment en mathématiques pour démontrer / valider / vérifier des conjectures ou théorèmes (certains théorèmes démontrés par ordinateur nécessitent cette puissance).
Tu oublies aussi certainement les entreprises qui ont de grosses données à manipuler très régulièrement comme les assurances ou les banques. Tout le "big data" peut nécessiter de telles configurations suivant le but visé.
Bref, il y a un marché, un réel besoin pour de telles machines et cela ne risque aps de s'arrêter de si tôt.
Ce qui est bluffant, c'est de se dire que nos machines modernes haut de gammes seraient en tête du top 500 d'il y a 15 à 20 ans seulement ! Même si la progression de la puissance des machine ralentie, cela laisse entrevoir malgré tout le potentiel qu'on pourrait avoir à la maison un jour.
[^] # Re: Ou est-ce que je me plante ?
Posté par KiKouN . Évalué à 8.
Un exemple récent :
https://lejournal.cnrs.fr/articles/la-plus-grosse-preuve-de-lhistoire-des-mathematiques
Ce que j'adore, c'est la puissance déployée pour un si petit nombre au final : 7 824.
[^] # Re: Ou est-ce que je me plante ?
Posté par Mikis . Évalué à 10.
Ce n'est rien par rapport à ce qu'il a fallu pour trouver 42.
[^] # Re: Ou est-ce que je me plante ?
Posté par Kerro . Évalué à 7.
Il y a tout de même une différence importante : on n'a pas perdu la question à laquelle correspond le résultat 7824.
[^] # Re: Ou est-ce que je me plante ?
Posté par KiKouN . Évalué à 3.
Non, il y a mieux pour cela : Le bitcoin. On parle quand même de 15 000 exaFLOPS. Sans parler des autres monnaies.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ou est-ce que je me plante ?
Posté par KiKouN . Évalué à 3.
Je ne pense pas que le bitcoin soit rentable sur ces machines. Ceux qui minent le bitcoin sur autre chose que des asics sont des personnes désirants chauffer leurs apparts du manière légérement plus rentable que d'allumer un radiateur.
Par contre, du Monero ( Carte graphique et CPU avec AES-NI ), là il y a moyen. Pour donner une idée, un Xeon doit permettre d'obtenir entre 0,20€ et 0,30€ par jour et une bonne carte graphique ( pas les nouvelles GTX 1080 et RX 480 ) environ 0,60€ par jour avec le cours actuel. Je pense par contre que les arm sont encore à la ramasse de ce côté. Grossomodo, pour un particulier, la moitié part en éléctricité ( les nouvelles cartes graphiques doivent avoir une meilleur rapport ).
[^] # Re: Ou est-ce que je me plante ?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 07 juillet 2016 à 10:27.
Essaye de faire tourner Linpack dessus pour voir la puissance réelle et non celle théorique si tout va bien et que ça lance les pseudo-thread exactement au même moment comme il faut avec les données qu'il faut en mémoire placées comme il faut.
tu risques d'être surpris par la différence entre réel et théorique.
Sans compter l'interconnexion entre les cartes (ça prend du temps aussi).
Je lis
Peak: 7,235.2 TFlop/s
2,834 kW
Pour atteindre 7 235 200 GFlop/s il faut donc théoriquement 7 235 200 / 24 = 300 000 Raspberry Pi. Reste plus qu'à les connecter entre eux (quel coût et combien de perte de puissance?) et être sûr que tu as vraiment 24 GFlop/s avec Linpack (j'ai perso de gros doutes).
Edit : trop lent, grillé :)
# SUMMIT : Summit The Next Peak in HPC
Posté par Dabowl_75 . Évalué à 3.
Personnellement, j'attends avec une relative impatience de voir ce que donnera Summit (le futur remplaçant de Titan) :
https://www.olcf.ornl.gov/summit/
Cela permettra de voir ce que vaudra vraiment le Power9 couplé à bus spécifique (NVLink) pour l'accès aux GPUs.
Le nombre de noeud sera considérablement réduit par rapport à Titan.
Reste à voir l'efficacité énergétique.
Le Power n'est pas mort, en revanche je ne vois pas ce que calculateur tourner sous AIX :-)
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par tao popus . Évalué à -3.
Enfin, d'un autre côté, ce que je pense de plus en plus des technologies, US, du Hitech thoérique toptop, des technologies à la pointe, mais final, ça coûte tellement cher que ça marche pas et/ou ça se fait dépasser :
D'après moi, l'architecture intel est trop complexe à la base, à des décennies de patch pour tenter d'être compatible pour conserver le marché juteux,
p.s.: J'ai l'impression d'avoir énuméré les pires choses qu'on fait sur terre.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par Kerro . Évalué à 3.
Au cas où ce ne serait pas de l'humour, c'est de la pisse de chat tes pires choses : guerres, tortures, destruction de notre habitat, etc.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par reno . Évalué à 4.
Simple? Vraiment ?
https://en.m.wikipedia.org/wiki/Dam_failure
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par Zenitram (site web personnel) . Évalué à 6.
Et de la place, beaucoup de place.
Et de l'eau, beaucoup d'eau.
La France a aussi plein de barrage; mais bon, tout ce qui était faisable l'a été, on ne peut pas en mettre plus, donc il faut aussi autre chose.
Bref, ton contre-argument n'est pas généralisable.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par tao popus . Évalué à 1.
Par contre, dans le même principe, il y a des techniques genre conduites forcées, mais c'est pareil, ça ne peut être utilisé qu'à certains endroits, c'est de beaucoup plus faible puissance que les barrages, mais, ça à tout de même fait tourné des grosses industries lourdes (avant leur délocalisations) dans les Pyrénées, comme à Tarascon sur Ariège, ça continue de faire tourner encore quelques usines et d'alimenter les villes aux alentours. Des techniques comme les barrages au fil de l'eau, ou les Centrale hydraulique à tourbillons utilisés sur les cours d'eau en Suisse par exemple, sont beaucoup moins problématiques pour la faune/flore et assez efficaces pour des petites productions locales. Ils ont aussi beaucoup de montagnes et principalement des petits villages en Suisse… Ce sont des techniques encore plus simples (pas les contraintes de grosse pression des grands barrages. Le principe des centrales thermiques (nucléaire, charbon, etc), est à peu près le même on fait bouillir de l'eau, pour qu'elle fasse tourner des turbines, c'est juste plus compliqué et nécessites des ressources épuisables et toxiques.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il y a une hydrolienne dans la Loire pour une production d'électricité de proximité : http://www.decideursenregion.fr/Loire-Centre/Innover-En-Region/economie-mixte/developpement-durable-RSE/Une-hydrolienne-fluviale-testee-dans-la-Loire-a-Orleans, http://www.larep.fr/loiret/actualite/pays/orleans-metropole/2014/11/05/les-turbines-tourneront-en-loire-des-jeudi-ou-vendredi-une-premiere-en-france_11207571.html.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par Dabowl_75 . Évalué à 2.
le supercalculateur chinois est à base de cpu chinois. Tu appelles ça du standard ?
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par X345 . Évalué à 4.
Et il utilise un interconnect spécifique (pas de l'ethernet standard…), comme une bonne partie des supercalculateurs. Bref, il est tout sauf standard (interconnect spécifique, processeur manycore spécifique, jeu d'instruction spécifique etc.).
Quand à la remarque sur le prix, m'étonnerai pas que la Chine soit prête à lacher des masses de pognon pour gagner le concours de celui qui a le plus gros supercalculateur avec les USA. Donc si ça se trouve le processeur SW26010 est hors de prix.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par Jerome . Évalué à 6.
Pour le prix :
sinon la Chine n'est peut être pas "prête à lâcher des masses de pognon pour gagner le concours de celui qui a le plus gros supercalculateur avec les USA", mais pour obtenir son indépendance, la clairement oui :
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par tao popus . Évalué à 1.
Le jeu d'instruction est plus ou moins basé sur le processeur Dec Alpha, qui était utilisé autrefois dans des gros serveurs, Linux fonctionne dessus depuis belle lurette. Mis à part ce processeur, comme le disent les articles, ils ont choisi des solutions économiques et courantes pour leur cartes mères, plutôt que des bus plus performants et plus onéreux. DDR3 (au lieu de DDR4, PCIe 3.0 au lieu d'un bus spécialisé), un Linux standard, que des compilateurs C/C++/Fortran standards (ça doit être du gcc je suppose).
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par Prosper . Évalué à 2. Dernière modification le 12 juillet 2016 à 11:57.
Les russes ( ni les indiens ) n'ont pas encore de chasseur de 5eme génération en service. Au mieux ils ont le SU-35 un 4++ plus proche de l'enclume volante ( quand il ne se crache pas ) le tout sur un design des années 60.
La maniabilité n' as plus aucun interêt que faire joli lors des meeting aérien. Ca fait 20 ans ou plus que les dogfights ça sert a rien. Un chasseur moderne se doit de faire du BVR , et sur ce plan les US sont largement en avance.
Quand au F22 , c est avant tout un intercepteur/superiorité aérienne , il a pas grand chose à faire sur les terrains de guerre actuels , même si il y est allé d'ailleurs . et Le F35, bin il est pas encore admis en service actif.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par flan (site web personnel) . Évalué à 8.
Le Su-27 date des années 70 (premier vol en mai 1977, avec une grosse refonte des premiers prototypes au début des années 80) et non des années 60. Accessoirement, ces histoires de génération n'ont strictement aucun sens, elles ont été lancées par le service marketing de Lockheed et de l'USAF, en prenant uniquement les caractéristiques qui avantageaient le F-22.
Avant le F-22, personne n'avait jamais parlé de génération 2, 3, 4… de chasseurs. D'ailleurs, on se demande bien quelles seraient les générations précédentes :
Bref, ça ne correspond à absolument rien. Le seul intérêt est de pouvoir dire que le F-22 est le seul avion de 5ème génération et que les autres sont pourris (bouhhhh ! à peine du 4++++ !). Alors, oui, le F-22 est sûrement bien meilleur que le Su-35 en air-air, mais c'est simplement absurde de qualifier le Su-35 d'enclume volante. Le Su-35 vole bien, très bien même, avec une capacité d'emport qui est bien plus importante que celle du F-22. 14 points d'emports, 8 t d'armement, avec notamment des armes air-sol bien utiles en ce moment.
Le Su-35 (et tout le reste de la famille, bien nombreuse) vole, et surtout a l'avantage par rapport au F-22 et au F-35 d'être à la fois utile et utilisé. Ce n'est pas rien :)
Largement en avance, sans avoir de missile digne de ce nom ? Le AIM-120 a quand même les pattes un peu courtes (dans les 80 km) par rapport aux missiles qui apparaissent (Meteor, R-77M) qui tapent plutôt dans les 150 km. C'est physique : un statoréacteur porte plus loin qu'un simple moteur à poudre. Au passage, les ÉU ont beaucoup sacrifié pour la furtivité, un concept de 40 ans qui risque de ne plus valoir grand-chose en pratique : beaucoup de pays travaillent depuis des années pour contrecarrer ça, les solutions théoriques sont connues depuis longtemps si elles ne sont pas déjà existantes en pratique. Ça avait un sens au début du F-22 (les années 90), mais ça fait dans les 30 ans maintenant.
Accessoirement, ils n'ont que 187 F-22, avec une disponibilité qui a priori laisse encore à désirer. Les guerres ont souvent montré qu'il valait mieux beaucoup d'armes avec une bonne disponibilité que peu d'armes high-tech qui fonctionnent une fois sur deux.
Accessoirement, tu as l'air de mieux connaître le sujet que Lockheed et le Pentagone : la maniabilité extrême faisait partie du cahier des charges du F-22. Dommage qu'ils ne sachent pas que ça ne sert plus à rien ! :)
Et bien si, justement. L'IOC a été déclarée pour le F-35B il y a un an et il est officiellement prêt au combat. Bon, apparemment, pas au point d'y aller en vrai, à croire que ça ne va pas si bien que ça…
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par pasBill pasGates . Évalué à 2.
En même temps envoyer au combat des avions dernière génération qui coûtent énormément à l'heure de vol pour balancer un missile sur un pickup dans un espace aérien sans aucun adversaire …. Pas très rentable, un escadron de drones fait tout aussi bien le boulot.
Le problème du F22/35 c'est le manque d'ennemi, leur développement a suivi une doctrine qui datait de la guerre froide.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par flan (site web personnel) . Évalué à 2.
Oui, c'est vrai aujourd'hui. On le voit bien avec les Américains qui se vantaient lors de leur premier raid en Syrie d'avoir détruit un mortier et une dizaine de pickups (bref, quelques dizaines de milliers de dollars de dégâts) avec un raid qui a couté plusieurs (dizaines de ?) millions de dollars.
Accessoirement, des drones se feraient descendre assez facilement en Syrie. Les Syriens ont perdus des dizaines d'avions de chasse), alors qu'ils vont bien plus vite, sont un peu blindés et mieux équipés.
Mais qu'en sera-t-il dans 10 ans ? Tous les pays du monde (sauf l'Europe) sont en train de se réarmer de façon importante. De plus en plus de pays veulent construire leurs propres armements, y compris leurs avions de combat.
Maintenant, sachant qu'un avion de combat demande en gros une quinzaine d'années entre les premiers travaux et l'entrée en service, est-il raisonnable de faire l'impasse dessus et de ne croire qu'il n'y en aura plus jamais besoin ?
Ce n'est pas parce qu'il n'y a pas eu de conflit en Europe de l'Ouest pendant 70 ans que le reste du monde se porte mieux.
Dans le domaine militaire, quand on fait une erreur de ce type, la sanction peut être très dure et se chiffrer en dizaine de milliers de vies.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par pasBill pasGates . Évalué à 4.
Dans 10 ans ? Le F-15 est apparu en 1972, il domine toujours les airs partout ou il va, ca fait 40 ans grosso modo.
Le F-22 est apparu il y a peu, et dans 10-15 ans il sera devenu inutile en comparaison avec des drones dérivés de prototypes genre X-47B qui font à peu près tout : décollage depuis porte-avion, ravitaillement en vol, …
Même pour ce qui est du combat rapproché quand tu y penses, un drone peut prendre un nombre de G absolument fou car il n'a pas besoin de s'occuper de l'humain à l'intérieur, peut réagir bien plus rapidement qu'un pilote, ne souffre pas du stress quand un missile est derrière, …
Les systèmes de navigation existent déjà, les drones armés aussi, etc… bref dans très peu de temps, ces drones remplaceront les avions avec pilotes. Le F-22 n'aura plus grand chose à faire et il n'aura pas servi bien longtemps, le F-35 je n'en parles même pas.
[^] # Re: SUMMIT : Summit The Next Peak in HPC
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Le barrage d'Itaipu est 50% au brésil et 50% au Paraguay ! 10 turbines font du 60Hz (brésil) et les 10 autres font du 50Hz (Paraguay) sachant qu'il y en toujours 1 sur les 20 à l'arrêt.
# Commentaire supprimé
Posté par lucette123 . Évalué à 0. Dernière modification le 28 juillet 2016 à 14:40.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.