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 !
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 !
> Lire le journal (39 commentaires, moyenne: 3,7).
Vous avez demandé le commentaire #845760.
Run by 
Cette page a été générée par Templeet en 0.0514s (dont 0.0057 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
.
J'ai du mal à me rendre compte. Y'a un matheux qui pourrait nous estimer combien de temps il faut pour casser un RSA 56 bits avec ce genre de machines ? Et avec un PC de bureau ordinaire de nos jours ?
[^]Re: .
Je ne suis pas spécialement matheux mais je peux essayer de donner un début de réponse...
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: .
A mon avis la question initiale ne portait pas sur une clé RSA de 56 bits (comme cela a été écrit sans doute par erreur) mais sur une clé d'un algo symétrique (type DES) de 56 bits.
[^]Re: .
Si si, tu as fait avancer le débat :
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à ?