Enfin ! Depuis le temps qu'on en parle et que les performances des super-ordinateurs s'en rapprochent de plus en plus, voici enfin le premier monstre qui atteint le petaflop (un million de milliards d'opérations à virgule flottante par seconde).
C'est IBM qui a tiré le premier avec la version 2 de son architecture BlueGene. En passant de 410 teraflops en pointe pour la version 1 (BlueGene/L) à exactement un petaflop en pointe pour cette nouvelle version BlueGene/P. Le bond est conséquent (+144%) et on note que la consommation augmente beaucoup moins puisqu'elle passe seulement de 1,7 MW à 2,3 MW (+36%).
La page http://www-03.ibm.com/servers/deepcomputing/bluegene.html présente cette seconde version mais le plus intéressant est évidemment la comparaison entre les deux machines.
L'architecture BlueGene avait fait le pari d'une densité maximum des noeuds de calcul en abaissant la fréquence des processeurs (700 MHz) afin d'avoir une consommation électrique réduite et peu de dégagement de chaleur. BlueGene/P poursuit cette philosophie en doublant le nombre de cores (4 au lieu de 2) et en augmentant faiblement la fréquence (850 MHz).
Le cache L3 est également multiplié par deux et la RAM par quatre.
Comparaison : http://www-03.ibm.com/servers/deepcomputing/bluegene/bgcompa(...)
Il est à noter que cette capacité d'un petaflop est uniquement atteinte en pointe (autrement dit les applications réelles ne parviennent jamais à l'atteindre). Cela n'invalide donc pas toute la phase de recherche hpcs (High Productivity Computing Systems) initiée par la DARPA depuis plusieurs années [http://linuxfr.org/2003/11/21/14642.html] afin d'obtenir des machines ayant une capacité petaflop soutenue.
Et maintenant quel est le rapport avec Linux me direz-vous ?
C'est simple : Linux est utilisé presque partout dans cette machine !
Certes les noeuds de calcul fonctionnent avec un noyau propriétaire extrêmement léger (réduit à sa plus simple expression) mais les noeuds d'entrée/sortie utilisent Linux. Les noeuds de service ainsi que le front end se basent quand à eux sur Suse Linux SLES 10.
Je crois que nous pouvons donc adopter fièrement le slogan suivant: Linux, le premier petaflop OS !
Journal BlueGene/P...enfin le petaflop !
27
juin
2007
# La grande question...
Posté par Snarky . Évalué à 9.
[^] # Re: La grande question...
Posté par hervé Couvelard . Évalué à 9.
[^] # Re: La grande question...
Posté par liberforce (site web personnel) . Évalué à 9.
# Troll de compet'
Posté par JereMe . Évalué à -1.
[^] # Re: Troll de compet'
Posté par patrick_g (site web personnel) . Évalué à 3.
Les CPU travaillent en double précision (c'est bien le moins pour un super-ordinateur destiné aux applications scientifiques).
[^] # Re: Troll de compet'
Posté par mateo70 . Évalué à 0.
Sinon la mahine du CEA a fait un flop dans le classement.
[^] # Re: Troll de compet'
Posté par patrick_g (site web personnel) . Évalué à 5.
Je pense que la différence entre les 370 et le 410 c'est justement le delta entre puissance théorique et puissance réelle.
Quand à la machine TERA du CEA elle est basée sur l'architecture Itanium d'Intel (des montecito double-coeurs) et comme Itanium est un peu à la ramasse cela explique la domination d'IBM.
Maintenant il parait que le CEA a vraiment fais le choix de cette architecture pour des raisons techniques (et pas pour les beaux yeux de Bull). Ce serait une histoire de granularité de la puissance : pour le type de calcul du CEA (simulation nucléaire) il faudrait des CPU puissants en moins grand nombre alors que BlueGene propose beaucoup de CPU moins puissants.
Si un spécialiste pouvait nous confirmer ce point ?
[^] # Re: Troll de compet'
Posté par Kibos . Évalué à 5.
http://www.cea.fr/content/download/3409/16810/file/Tera10_ja(...)
Un calculateur, ce n'est pas seulement la puissance CPU, mais aussi
le débit du réseau,
la latence du réseau,
le stockage,
la mémoire par CPU,
le cache par CPU,
la scalabilité,
la qualité du refroidissement,
la durée de vie des n½uds,
la tolérance aux pannes,
sans oublier l'efficacité des compilateurs, des bibliothèques...
[^] # Re: Troll de compet'
Posté par mdlh . Évalué à 3.
Ca c'est l'explication technique qui explique le resultat du choix. Le choix c'est:
"Salut tout le monde. J'ai un benchmark qui represente ce que je veux faire. Je veux la solution la moins chere qui atteint le score de xxxx. Que le meilleur gagne."
Voila. C'est BULL qui a remporte le concours.
[^] # Re: Troll de compet'
Posté par Émilien Kia (site web personnel) . Évalué à 3.
1 flop seulement ? C'est Enormément Ancien ;-).
Un jour libre ?
[^] # Re: Troll de compet'
Posté par Obsidian . Évalué à 1.
[^] # Re: Troll de compet'
Posté par inico (site web personnel) . Évalué à 2.
Ca devient un acronyme naturel :)
[^] # Re: Troll de compet'
Posté par Mais qui suis-je ? :) . Évalué à 4.
J'ai un collegue malin qui pour les codes ( scientifique ) pour lesquels il à besoin de rapidité travaille uniquement avec des entiers.
Son argument est le suivant
Mon instrument est precis a 0.2 ns près donc si je multiplie par 5 j'en ait plus rien à foutres des chifres après la virgule vu que de toute façon ils n'ont aucun sens.
Bref tout dépend du but de ton application
si c'est pour faire une simulation alors oui il faut travailler au sens des doubles car la précision est importante.
Par contre si c'est pour travailler avec des données ça sert a rien d'être plus precis que la sonde qui mesure, au contraire c'est gaspiller de la puissance.
Après je ne me suis jamais poser la question de l'uttilité de ce genre d'astuce donc j'en profite est ce qu'un calculateur standard ( par exemple un Xeon où un Opteron ) est plus rapide avec des entiers qu'avec des flottants ou des doubles
[^] # Re: Troll de compet'
Posté par beagf (site web personnel) . Évalué à 3.
C'est en gros le principe du calcul en virgule fixe, la problème dans ce cas, c'est que généralement les chiffres après la virgule on ne s'en fout pas. Il y a souvent des calcul à faire sur les chiffres sortis par l'instrument, et donc si on ne prévoit pas de la marge, du genre multiplier par 50 ou 500 au lieu de 5, on se retrouve vite avec de grosse erreurs d'arrondis difficiles à débugger.
Deuxième problème, les économie ne sont plus aussi énormes qu'avant. Les calcul flottants sont devenus très rapide, et il ne faut pas oublier que le calcul en virgule fixe nécéssite en permanence d'ajuster les résultats. Par exemple la multiplication demande en fait de faire une multiplication et une division. Pour multiplier A et B en vigule fixe avec une precision de 100 il faut faire A * B / 100 en faisant gaffe aux débordements.
A part pour des cas spécifiques, l'utilisation de la virgule fixe est de moins en moins justifiée et conduit le plus souvent à des programmes pas beaucoup plus rapide dans le meilleur des cas, mais par contre beaucoup plus buggés.
Par contre si c'est pour travailler avec des données ça sert a rien d'être plus precis que la sonde qui mesure, au contraire c'est gaspiller de la puissance
Pour stocker la mesure, en effet il n'y a pas besoin d'une plus grande précision, mais pour faire du calcul scientifiques dessus tu as interet à disposer d'une précision maximale si tu veux que tes calculs soient justes. En plus sur les processeurs actuels la différence en performance entre simple et double précision et minimime.
[^] # Re: Troll de compet'
Posté par mdlh . Évalué à 2.
Et y a meme certains CPU qui n'ont pas de multiplication en entier et tu dois faire une conversion en flottant avant...
[^] # Re: Troll de compet'
Posté par Mais qui suis-je ? :) . Évalué à 1.
Je range donc cet astuces au rayons des souvenirs des vieux briscard ayant connus les cartes perforées.
# .
Posté par snt . Évalué à 3.
[^] # Re: .
Posté par Babelouest (site web personnel) . Évalué à 7.
La complexité de factorisation d'un nombre quelconque est polynomiale, ce qui veut dire que grosso-modo, voire à bisto de nas ou encore peu ou prou, si on considère que la taille d'un nombre n est t, le temps de factorisation de ce nombre sera de e^t, à savoir que plus le nombre sera grand, plus sa durée de factorisation sera grande exponentiellement. La factorisation d'un nombre est une méthode de décryptage d'un message codé via RSA.
Selon l'article de Wikipedia : http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman#S.C3.A9cu(...) ,
Sachant qu'une clé RSA 56 Bits est plus petite qu'une clé RSA 256 bits, j'en déduis deux choses :
- Il faut peu de temps pour casser une clé RSA 56 bits avec un ordinateur individuel, même sous KDE dans une appli écrite en Javascript et lancée sous Firefox
- J'ai répondu à coté de la plaque en ne comprenant pas le sens de la question de sieur snt
Selon ces déductions, je me permet d'élaborer l'hypothèse suivante : Si quelqu'un essaie de casser une clé RSA 56 bits avec BlueGene/P, je suppose que ca va prendre peu de temps. La notion "peu" étant vague, je me permet d'envisager que la clé serait classée plus rapidement que le temps qui a été nécessaire à sa création. Voire même que le code serait cassé avant même que le message ne serait encodé avec ladite clé.
Sachant, toujours selon Wikipedia que il est couramment recommandé que la taille des clés RSA soit au moins de 2048 bits., je suppute que même BlueGene prendrait un temps certain, pour ne pas dire un certain temps à décrypter une clé RSA 2048 bits. Ce temps étant suffisamment long pour qu'on n'ait pas le temps de le voir venir, la comparaison avec le temps nécessaire pour qu'un ordinateur de bureau classique décrypte une clé RSA 2048 bits serait grandes, certes mais tout aussi inutile car comparer deux grands nombres ne sert pas à grand-chose dans le cas qui nous intéresse.
Je terminerai donc sur un regret, celui de ne pas avoir fait avancer le débat et me replongerai derechef dans ma recherche de la pierre philosophale que j'ai paumé dans mon dernier déménagement...
[^] # Re: .
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: .
Posté par khivapia . Évalué à 6.
ton post est juste et on est près de la conclusion : (si ce n'est que la complexité de factorisation d'un nombre n'est pas, a priori, polynômiale mais bien non polynômiale ;-) ) si n est de taille t le temps de factorisation de n est de l'ordre de e^t.
(pour ceux qui en veulent un peu plus : voir un exemple de complexité pour le meilleur algo connu sur http://fr.wikipedia.org/wiki/Crible_général_de_corps_de_nombres_(GNFS) sachant que log(n) est peu ou prou le nombre de bits de n)
Id est : augmenter la taille d'un bit multiplie le temps de calcul par une constante.
On va dire que cette constante est 2 (ça serait plus, avec la complexité précédente, un peu plus de 1/3*64/9*1 soit e^2.37 = 10,7 voir plus bas) :
Alors augmenter la taille de 256 bits à 2048 multiplie le temps de calcul par 2^(2048-256) > 10^306 ! Soit plus, bien plus de 10^306 heures avec un PC actuel s'il met une heure pour calculer une factorisation de 256 bits.
Un PC actuel fait 1 GigaFlop mettons (1 GHz, bon c'est pas tout à fait vrai pour les flottants, et de toutes façons la factorisation ne fait appel qu'à des entiers, mais bon on calcule à la louche, hein ;-) )
1PetaFlop/1GigaFlop = 10^15Flop/10^9Flop = 10^6 ; le Blue Gene mettra 10^6 fois moins de temps que le PC de base pour faire la décomposition de la clef RSA, soit 10^300 heures !
(à titre de comparaison 1 an fait un peu moins de 10^4 heures... ça fait pas beaucoup à côté ! )
Bon évidemment c'est sous réserve que personne ne trouve entre temps d'algo plus rapide/de vice dans le principe/ne construise d'ordinateur quantique
Explication du 2.37 : en gros il faut a*e^{(64/9t)^{1/3}} opérations pour un nombre de logarithme t (la constante a vient du grand O, et on néglige la variation du log(log(n))) ; si t->t+1 (on augmente la taille de n, égale ici à son logarithme, de 1) on passe au temps a*e^{ (64/9 (t+1))}{1/3}} à peu près égal (développement limité à l'ordre 1 du terme à a*e^{(64/9t)^{1/3}+(1/3)*(64/9)*1} si t grand devant 1. d'où une multiplication du temps par e^(1/3)*(64/9)*1 d'où le résultat)
Note : résultats bien entendu non garantis ;-) à vérifier si quelqu'un passe par là ?
# un petaflop en continu
Posté par BAud (site web personnel) . Évalué à 2.
Perso, j'aime bien ce commentaire [http://hardware.slashdot.org/comments.pl?sid=241601&cid=(...)] listant des applications de CFD (Computationnal Fluid Dynamics) que ce soit pour la météorologie ou les calculs industriels, parlant de MPI (Message Passing Interface) ou OpenMosix ou Kerrighed pour la parallèlisation de traitements, les traitements d'images 2D ou 3D (raytracing)...
Sinon, ya sans doute des utilisations en mécanique quantique envisageable ?
[^] # Re: un petaflop en continu
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: un petaflop en continu
Posté par BAud (site web personnel) . Évalué à 3.
- à terme, dans le futur, d'après zdnet, il est conçu pour 3 petaflop en pointe
- à terme, il est conçu pour plus de 1 petaflop atteint en continu (la métrique étant sans doute le sens du vent :) de manière plus réaliste la capacité des applis à réclamer de la CPU).
Ce qui est ballot tout de même, c'est que la métrique semble rester la CPU alors que dans mon boulot c'est plutôt la RAM le facteur limitant : l'informatique de gestion (oops pardon, l'information technology) c'est beaucoup beaucoup de données à traiter (et des développeurs persuadés que tout charger en mémoire est la bonne manière d'optimiser /o\). Côté CPU, si plus de 20%-40% sont utilisés sur la journée en moyenne c'est que l'appli est consommatrice (et bien développée) ou alors qu'elle traite du XML :/.
Bien sûr, au niveau du système d'information, de ce que j'en ai vu, c'est malheureusement une logique "batch" qui perdure plutôt que d'essayer de lisser la charge par du fil de l'eau...
Mais bon, le coeur de cible de ces monstres semble plutôt être le calcul en force, l'indicateur de CPU n'est pas forcément inintéressant... (quoique traiter de gros volumes d'informations ne devrait pas trop leur faire peur si les I/O suivent).
[^] # Re: un petaflop en continu
Posté par patrick_g (site web personnel) . Évalué à 3.
Si je compte bien cela fait une RAM max = 73728 x 2Go = 147456 Go
Près de cent cinquante mille gigaoctets de RAM cela me semble assez imposant ;-)
[^] # Re: un petaflop en continu
Posté par Gniarf . Évalué à 5.
[^] # Re: un petaflop en continu
Posté par fleny68 . Évalué à 4.
[^] # Re: un petaflop en continu
Posté par briaeros007 . Évalué à 4.
C'est le bench linpack , utilisé entre autre pour top500 qui est souvent retenu ;)
http://top500.org/project/linpack
# Attention, Plan9 !
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
... et IBM travaille à porter Plan9 sur chaque noeud de Blue Gene.
Et pourquoi choisir Plan9 me demanderiez vous ?
Simple : ces monstres s'apparentent de plus plus à des systèmes distribués dont chaque noeud est en étroite communication via des liens réseaux dédiés. Il est donc nécessaire, afin de profiter au mieux de ce type d'architecture, de disposer sur chaque noeud (noeud de calcul et d'entrée-sortie) d'un OS qui repose sur une architecture distribuée et qui offre donc l'opportunité aux services sur les noeuds de pouvoir aussi être répartis. C'est ce que permet justement Plan9 avec son protocol 9P2000.
Est-ce le signe d'un renouveau pour Plan9 ?
(il existe déjà une distribution de Plan9 : Inferno, vendu par Via Nuova
http://www.vitanuova.com/
)
Quelques liens pour en savoir plus :
http://domino.research.ibm.com/comm/research_projects.nsf/pa(...)
http://www.graverobber.org/
et un article sur slashdot qui en a parlé :
http://slashdot.org/article.pl?sid=07/06/19/1215253&from(...)
[^] # Re: Attention, Plan9 !
Posté par patrick_g (site web personnel) . Évalué à 1.
il me semblait bien avoir vu passer son inclusion lors de la lecture du changelog d'un des noyaux précédents non ?
Si 9P2000 est inclu je ne vois plus trop l'intérêt de Plan9 alors que Linux est quand même bien mieux testé et solide.
[^] # Re: Attention, Plan9 !
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
9P2000 est la brique de base sur laquelle est contruit Plan9 : en gros dans Plan9 tout est service et le système de fichier sert d'annuaire de ceux-ci. Même les pilotes : si je me souviens bien, par exemple, un pilote sur un Plan9 distant en kernel-space peut service sur un Plan9 local en user-space.
Il faut savoir que Plan9 a été conçu par le père fondateur d'Unix, Ken Thompson, avec d'autres personnes, en vue de pousser jusqu'au bout les concepts même d'Unix ; en gros de faire ce qu'aurait dû être Unix. Et 9P2000 est ce qui permet à Plan9 d'atteindre cet objectif.
# Mauvais slogan
Posté par moramarth . Évalué à 4.
Il ne vaudrait mieux pas pour Linux que cette phrase devienne son slogan. Un argument pour décider les grosses organisations ayant besoin de grosses puissances de calcul, oui, mais pour intéresser >99% de la population informatique mondiale, il vaut mieux ne pas balancer un slogan qui enfoncerait grandement l'idée que Linux, c'est pour les geeks bien techos dans les têtes.
[^] # Re: Mauvais slogan
Posté par Gniarf . Évalué à 5.
je préfère encore passer pour un geek bien techos, merci
[^] # Re: Mauvais slogan
Posté par moramarth . Évalué à 2.
Fais un effort, Think different :P.
# Et Nvidia/ATI ?
Posté par Ontologia (site web personnel) . Évalué à 6.
CUDA ( http://www.hardware.fr/articles/659-1/cuda-apercu.html ) est une sorte de compilateur/API au dessus de C permettant de refiler tous les calculs en flottants (matriciels, etc...) à la carte graphique, offrant la possibilité d'exploiter au mieux son parallélisme.
Le GPU G80/NV50 est doté de 128 unités de calculs. La plupart sont capables d'exécuter des additions et multiplications flottantes, ou des instructions du type FMAD qui effectue une multiplication plus addition (idéal pour les multiplications de matrices).
Certaines unités d'exécution proposent des instructions plus puissantes comme sinus, cosinus, racine carrée, etc...
16 "multiprocesseurs" contiennent chacun 8 processeurs et 8 ko de mémoire cache.
Pour le moment, CUDA ne permet de n'atteindre qu'une précision de 32 bits sur les flottants, mais les 64 devraient arriver bientôt.
De plus, la circuiterie interne des GPU n'est pas compatible IEEE
CUDA nécessite un driver spécifique disponible pour plusieurs OS dont Linux qui est ici bien servi.
Il propose une lib contenant des opérations pour FFT et de l'algèbre linéaire de base. Il y a même un plugin Matlab !
Bien évidemment la lib permet aussi d'injecter des résultats de calculs dans un rendu 3d.
C'est censé fonctionner avec GCC, mais j'ai pas testé, donc à vérifier.
http://developer.nvidia.com/object/cuda.html
De plus, Nvidia s'apprête à sortir TESLA. Tesla http://www.nvidia.com/object/tesla_computing_solutions.html est un serveur lame intégrant plusieurs GPU et permettant, grâce à Cuda, d'exécuter toute sortes de calculs.
Il faut voir qu'un G80 (le processeur de la Gforce8800) atteint 300 Gflops, en calculs très spécialisé certes, mais 300 Gflops pour tout ce qui est calculs physique, génétique, réseau de neurones, etc...
Cette machine offre une infrastructure pour gérer le parallélisme.
Bref, je me demande si ce genre d'approche ne va pas séduire pas mal d'industriels, parce que 300 Gflops par GPU, il n'en faut que 3000 pour atteindre le pentaflop...
NB : il y a aussi CTM d'ATI mais il parait que c'est assez difficile à utiliser.
http://ati.amd.com/companyinfo/researcher/Documents.html
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et Nvidia/ATI ?
Posté par BAud (site web personnel) . Évalué à 2.
Le projet nouveau pourrait d'un coup prendre une nouvelle envergure ;-) [http://nouveau.freedesktop.org/wiki/Accueil-fr#A_propos]. Tiens d'ailleurs TiNDC est sorti : http://nouveau.freedesktop.org/wiki/Nouveau_Companion_22 (bientôt la traduction française j'espère).
[^] # Re: Et Nvidia/ATI ?
Posté par Ontologia (site web personnel) . Évalué à 1.
Oui, bien sûr, mais pour les cartes récentes, muni du driver adéquat.
Le projet nouveau pourrait d'un coup prendre une nouvelle envergure ;-) [http://nouveau.freedesktop.org/wiki/Accueil-fr#A_propos].
Effectivement c'est techniquement possible, mais en fait non, il me semble, car NVIDIA fourni un sdk sous Linux.
Le problème est que ça n'offre la possibilité d'utiliser la carte graphique pour calculs que si le driver CUDA est installé.
Ca pourra peut être servir pour la rétro-ingénieurie ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Je comprends pas
Posté par ciol . Évalué à 2.
[^] # Re: Je comprends pas
Posté par beagf (site web personnel) . Évalué à 8.
Dans la réalité ce n'est pas aussi simple, mais l'idée c'est consiste souvent à diviser ton problème en plein de petites tache que différent coeur peuvent résoudre et ensuite réunir les ptites réponses pour obtenir le résultat final.
Les systeme en peer-to-peer de type seti@home sont adaptés quand le cout de transfert est vraiment négligeable par au temps de calcul, car c'est le genre d'architecture ou les noeuds ne peuvent communiquer entre eux.
Les clusters comme présentée ici sont utiles notemment quand les noeud doivent pas mal communiquer entre eux. À ce moment la programation peut devenir très complexe et la mise au point des algos difficile. Il est très dur de tirer le maximum de ce genre d'architecture et tous les problème ne si prettent pas.
A une echelle moindre on peut imaginer des ordinateur personel avec 4 coeur par exemple. Pour un jeux, il y a un coeur qui est dedier à la phisique, un au graphisme, un pour les IA et un pour l'interaction avec le joueur.
Ce qu'il faut voir c'est que c'est le même principe, on a un gros problème à résoudre que l'on divise en plus petit morceaux suffisament indépendants pour etre éxécutés sur différent coeurs.
[^] # Re: Je comprends pas
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
En plus dans le cas de ta boucle, c'est itératif donc non paralélisable, il faudrait voir son utilité pour faire mieux;
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.