Le Top 500 de novembre 2012

Posté par (page perso) . Édité par baud123 et Xavier Teyssier. Modéré par tuiu pol. Licence CC by-sa
64
12
nov.
2012
Technologie

Le quarantième Top 500 des supercalculateurs mondiaux est sorti aujourd’hui à l’occasion de la conférence Supercomputing 2012 qui a lieu à Salt Lake City aux États‐Unis.

Rappelons que le Top 500 se base sur une soumission volontaire (de nombreuses machines, puissantes mais classifiées ne participent pas à la course) et sur un comparateur spécifique de performances extrêmement parallélisable (le code Linpack qui concerne la résolution de systèmes d’équations linéaires).

L’analyse dans la suite de la dépêche…

Le numéro un de ce nouveau Top 500 de novembre 2012 est la machine Titan, qui souffle ainsi la première place au Sequoia d'IBM qui était le champion en titre.

Titan

Titan est un Cray XK7 installé au laboratoire d'Oak Ridge et il constitue une profonde mise à jour de la machine Jaguar (qui elle même avait dominé les Top 500 de novembre 2009 et juin 2010).

Pour passer de Jaguar à Titan, c'est très simple. On garde le même nombre de nœuds de calcul (18 688), mais on remplace les processeurs AMD Opteron 2435 à six coeurs par des AMD Opteron 6274 à seize coeurs. Au passage, on double la mémoire par nœud de calcul en passant de 16 Go à 32 Go. Grande nouveauté, on ajoute à chacun des 18 688 noeuds un coprocesseur NVidia Tesla K20 qui vient avec ses 6 Go de mémoire dédiée. Enfin, le nombre de nœuds d'entrées/sorties passe de 256 à 512, afin de faciliter les échanges de données.

Au final, on obtient donc un monstre de 17,59 Pétaflops, 710 To de RAM et 10 Po de stockage sur disque. La consommation est de 8,2 MW (soit 2 143 MFlops/W), ce qui est un très bon chiffre pour la puissance de calcul délivrée.

La seconde position du classement revient donc au Sequoia avec 16,32 Pétaflops. C'est exactement le même score qu'en juin 2012 lors du dernier classement. Le BlueGene/Q d'IBM n'a donc pas été modifié et il garde ses 1 572 864 coeurs de calcul en architecture POWER. L'efficacité est de 2 031,6 MFlops/W et on peut noter que Titan, en combinant des CPU et des GPU, arrive à offrir une meilleure efficacité énergétique que Sequoia et ses CPU développés spécialement par IBM.

Une machine intéressante, arrivée en septième position, est le supercalculateur Stampede construit par Intel pour le Texas Advanced Computing Center. Il s'agit d'une machine qui associe des Xeon E5-2680 avec des coprocesseurs de type Xeon Phi (anciennement connus sous le nom de Knights Corner). Stampede a obtenu un score Linpack de 2,66 Pétaflops, mais il annonce surtout une guerre sans merci entre Intel et NVidia pour s'approprier le marché des coprocesseurs de calcul. Est-ce qu'il vaut mieux parier sur un GPU adapté au calcul haute performance ou bien est-ce que l'approche d'Intel, consistant à privilégier la compatibilité x86, va finalement l'emporter ?
Il est difficile de faire des comparaisons puisque la consommation énergétique de Stampede n'a pas été dévoilée dans le classement.

Outre Stampede on peut remarquer, également, en 113ème position de ce classement, le tout premier calculateur XC30 de Cray. Il s'agit là d'une nouvelle génération de machine qui va sans doute beaucoup faire parler d'elle dans les futurs Top 500. Le XC30 est le résultat de l'initiative "Cascade" menée en coopération avec la Defense Advanced Research Projects Agency (DARPA) qui a versé plus de 250 millions de dollars à Cray pour développer cette architecture.
Ces machines peuvent accepter toutes sortes de coprocesseurs de calcul (des GPU, des Xeon Phi, des FPGA, etc) et elles reposent en grande partie sur la puce d'interconnexion Aries qui relie tous les cœurs de calcul via PCI-Express 3.0.
Selon les projections de Cray, l'architecture XC30 pourra atteindre les 100 Pétaflops (voir cet excellent article récapitulatif du site The Register).

Le ticket d'entrée dans le Top 500 est passé à 76,5 Téraflops, alors qu'il était de 60,8 Téraflops, il y a seulement six mois. L'écart est encore plus grand avec le seuil de la centième place qui passe de 172,7 à 241,3 Téraflops. La puissance agrégée des 500 machines passe à 162 Pétaflops, alors qu'il y a six mois, elle n'était que de 123 Pétaflops.
Une autre statistique intéressante est celle de nombre moyen de cœurs de calcul pour les supercalculateurs du Top 500. Cette moyenne s'établissait à 18 383 il y a un an… mais le chiffre d'aujourd'hui est de 29 796 coeurs ! On voit bien que les constructeurs multiplient les cœurs pour tenter d'augmenter la puissance de leurs machines.

En terme de classement par continents ou pays, la liste évolue peu. On retrouve les USA en position dominante (250 machines sur 500) et l'Asie en seconde position (124 machines au lieu de 122, la dernière fois). L'Europe est scotchée au alentours de 100 machines (105 exactement), mais elle place 3 supercalculateurs dans les 10 premiers (JUQUEEN et SuperMUC pour l'Allemagne, Fermi pour l'Italie).
La France conserve sa cinquième position au classement par pays avec 21 machines dans le TOP 500. Le plus puissant calculateur français est la machine Curie du GENCI (Grand Équipement National de Calcul Intensif) à Bruyères-le-Chatel. C'est Bull qui a construit ce supercalculateur en assemblant plus de 10 000 Xeon E5-2680 (8 coeurs), cadencés à 2,7 GHz. Le score Linpack est de 1,36 Pétaflops, ce qui le place en onzième position de ce Top 500.

En terme de système d'exploitation, la domination écrasante de Linux se maintient et, même, se renforce encore un peu plus. En un an, on est passé de 457 machines (91,4 %) à 469 machines (soit 93,8 % du classement).
Si seulement les chiffres sur le marché du bureau pouvaient être semblables…

  • # Revue

    Posté par . Évalué à  6 .

    Merci pour cet article !

    Un complément sur les supercalculateurs dans le magazine "La Recherche" du mois de novembre.
    Il s'agit d'un cahier supplémentaire de 40 pages sur ce sujet. Je l'ai eu en tant qu'abonné, je ne sais pas s'il est avec le magazine en kiosque.
    Pour le moment, je n'ai lu que les premières pages, intéressantes, donc pas d'avis sur le reste, mais "La Recherche" étant un mensuel de très bonne qualité, je ne me fais pas de soucis.

    • [^] # Re: Revue

      Posté par (page perso) . Évalué à  4 .

      il est avec le magazine en kiosque.

      oui, il l'est

      • [^] # Re: Revue

        Posté par . Évalué à  2 .

        Il est disponible gratuitement sur le stand Inria à Supercomputing aussi :)

        • [^] # Re: Revue

          Posté par (page perso) . Évalué à  2 .

          Un compte-rendu du supercomputing et du libre sur LinuxFr ?

          Ce serait bien que ce genre d'événement soit couvert aussi. Il y aurait plein de sujets techniques : genre code Aster tourne-t-il bien sur le top500 ? (scalabilité, portabilité, besoins métiers, complexité des modèles…).

          Je laisse à titre d'exercice les autres questions métier justifiant tant de ressource CPU/GPU (outre la vulcanologie, l'astrophysique, la tectonique des plaques et les autres modèles de vagues sur les récifs).

  • # Problème d'unités

    Posté par . Évalué à  6 . Dernière modification : le 13/11/12 à 00:38

    Je suppose que les Go de mémoire sont en fait des Gio.

    18688 nœuds x (32 Gio + 6 Gio) = 18688 x (38x1024x1024x1024) = 762,511313862656 x 1012 octets
    Soit 762,511 To ou 693,5 Tio
    Mais pas 710

    Ou encore 18688 nœuds x (32 Gio + 6 Gio) = 710144 Gio = 710144 / 1024 = 693,5 Tio

    • [^] # Re: Problème d'unités

      Posté par (page perso) . Évalué à  2 .

      La table des symboles Prefixes for binary multiples est, depuis 1998, une norme de l'IEC (International Electrotechnical Commission).

      Les Préfixes binaires doivent être utilisés pour compter les capacités en octets des systèmes informatiques.

      • [^] # Re: Problème d'unités

        Posté par . Évalué à  7 .

        Je n'ai pas compris le sens de ton message.

        Confirmes-tu le calcul ou pas ?
        J'aimerais savoir si je me plante ou pas.

        • [^] # Re: Problème d'unités

          Posté par (page perso) . Évalué à  4 .

          Non, je n'ai pas refait le calcul, j'ai confiance ! Je voulais seulement donner les références sur les unités.
          On n'insistera jamais assez sur la définition des interfaces. C'est ce qui permet de fonctionner ensemble. Ici, l'interface, c'est le système d'unités qui permet de bien se comprendre.

  • # Coût d'un calcul

    Posté par . Évalué à  5 .

    Je me demande à combien s'élève l'heure de calcul sur ce genre de bestiole et s'il existe à l'heure actuelle des codes qui permettent de les exploiter à 100 % de leur capacité.

    • [^] # Re: Coût d'un calcul

      Posté par (page perso) . Évalué à  8 . Dernière modification : le 13/11/12 à 09:20

      J'ai ajouté en troisième lien l'article d'Anandtech parce qu'il est très complet et intéressant. C'est une visite de Titan avec pas mal de détails. On trouve notamment, dans la section intitulée "Applying for Time on Titan", certaines réponses à tes questions.
      Par exemple pour la machine Jaguar le prix était de 0.05 $ par coeur de calcul et par heure. La facturation pour Titan sera basée sur les racks parce que le découpage en coeur à moins de sens du fait des GPU.
      L'article évoque également le sujet des codes de calcul et indique que les tems souhaitant utiliser Titan doivent la capacité de leur code à "scaler" avant de se voir attribuer du temps.

    • [^] # Re: Coût d'un calcul

      Posté par (page perso) . Évalué à  3 .

      A ma connaissance, aucun code si ce n'est le LINPACK pour le bench, utilise en production toute la machine… Ces chiffres sont donc vraiment à prendre avec des pincettes.

      Un nouveau benchmark devrait voir le jour ou une dizaine de VRAI applications seront moulinées, on aura alors un classement plus représentatif de la réalité. Je ne sais pas ou cela en est.

      Sinon, on voit bien dans la dépêche que l'état fédéral américain aide bien ses constructeurs ;-)

      • [^] # Re: Coût d'un calcul

        Posté par . Évalué à  6 .

        Sinon, on voit bien dans la dépêche que l'état fédéral américain aide bien ses constructeurs ;-)

        Exactement comme le CEA et Bull chez nous.

    • [^] # Re: Coût d'un calcul

      Posté par . Évalué à  3 .

      si on prend le coût électrique simplement de la machine, on arrive en france, à 120 € Mwh, soit pour une journée de calcul intensif prenant en compte tous les coeurs 8.2*120*24=23616 €.

      Pour 18 688 processeurs de 16 coeurs ça fait 0,329 centimes d'euros par coeur par heure de consommation électrique. et sinon ça fait environ 1000€ de l'heure en pointe, rien qu'en électricité.

      Si elle tourne toute l'année à bloque, ça coûte en électricité 8,619 millions d'euros par an ce qui vu le coût d'investissement est finalement raisonnable toute proportion gardée !

      • [^] # Re: Coût d'un calcul

        Posté par . Évalué à  0 .

        Et tu penses que les centres de calcul qui consomment autant paient l’électricité au même taux que le particulier …
        Le prix se négocie, et le taux appliqué est sous NDA.

        • [^] # Re: Coût d'un calcul

          Posté par . Évalué à  5 .

          Et tu penses que les centres de calcul qui consomment autant paient l’électricité au même taux que le particulier …
          Le prix se négocie, et le taux appliqué est sous NDA.

          ouha lala oui je suis trop bête … bien sur que je le sais … maintenant le prix de gros c'est 42 € plus les coûts d'acheminements plus la marge qui même si elle est négociée n'est pas nulle … donc ce n'est pas 120 le prix grand public mais ça donne un ordre de grandeur même si tu peux diviser les montants par 2 mais comme tu le dis si bien, on ne connaît pas le montant exact donc mon calcul à au moins l'intérêt d'avoir des notions sur l'échelle des coûts.

          • [^] # Re: Coût d'un calcul

            Posté par . Évalué à  3 .

            ok désolé pour le ton du message initial, c'était malencontreusement agressif.

            42€ c'est déjà trois fois moins cher et mon petit doigt me dit que c'est pas le minimum (pas de source … désolé).

            Pour reprendre ton "ordre de grandeur", ça met l'heure de calcul a 400€ au lieu de 1000€ et ça reste hypothetique puisque dépendant des négociations de la salle d'hébergement…

    • [^] # Re: Coût d'un calcul

      Posté par (page perso) . Évalué à  5 .

      Si je suis bien informé,
      Le code qui tourne cette semaine sur Titan s'appelle SPECFEM3D
      https://www.projet-plume.org/fiche/specfem
      http://www.geodynamics.org/cig/software/specfem3d

      Il a déjà tourné sur presque 900 noeuds cet été et le code devrait pouvoir occuper la totalité du cluster. les I/O seraient le maillon faible et nécessiteraient d'être réécrite en utilisant ADIOS du même laboratoire où est installé Titan http://www.olcf.ornl.gov/center-projects/adios/

  • # Coprocesseurs

    Posté par (page perso) . Évalué à  3 .

    « Stampede a obtenu un score Linpack de 2,66 Pétaflops, mais il annonce surtout une guerre sans merci entre Intel et NVidia pour s'approprier le marché des coprocesseurs de calcul.  »

    Justement, est-ce que quelqu'un au fait de la chose saurait nous dire où l'on en est en ce qui concerne l'utilisation réelle des coprocesseurs ? À l'époque où j'ai quitté les grosses machines, les investisseurs institutionnels achetaient à prix d'or des grappes de calcul avec des interconnexion de folie qui étaient ensuite massivement employées pour des calculs séquentielles, et les codes se convertissaient progressivement à la parallélisation. Qu'en est-il aujourd'hui des taux d'utilisation réelles des coprocesseurs Tesla et autres Xeon-phi ? Comment se passe la cohabitation avec les codes n'employant que du bête MPI ?

    • [^] # Re: Coprocesseurs

      Posté par . Évalué à  3 .

      Tous les gros codes de simulation numérique ont été parallélisés. Et la plupart ont également été portés sur GPU quand c'était possible/intéressant. Ce qui reste à paralléliser, c'est plutot des codes moins conventionnels (j'ai vu des exemples pour de la cyrpto récemment par exemple). Mais ca ne concerne pas la grosse majorité des utilisateurs de centres de calcul.

      Quant au portage sur Xeon Phi, evidemment c'est encore très peu fait. La grosse question est encore quel modèle de prog va être utilisé pour cette architecture. Intel fournit pas mal de modèles différents (offload par directive, offload manuel, MPI pur, …). Les gens vont peut-etre attendre un peu de voir les tendances avant d'investir du temps pour porter leur code. L'investissement devrait être moindre que sur GPU, mais ca ne sera pas complètement gratuit, faut pas rêver.

      Qu'est-ce que tu entends par cohabitation avec les codes MPI ?

      • [^] # Re: Coprocesseurs

        Posté par (page perso) . Évalué à  3 .

        « Qu'est-ce que tu entends par cohabitation avec les codes MPI ? »

        Si j'ai bien compris des nœuds typiques de machines modernes sont constitués de quelques dizaines de cœurs x86 associés à quelques coprocesseurs. L'objectif étant d'utiliser tout le monde à son plein potentiel en tout temps.

        Un code qui fonctionne bien sur les coprocesseurs exploitera probablement modérément les processeurs classiques. Inversement des codes massivement parallèles n'exploitent pas du tout les co-processeurs. Je m'interroge sur les techniques mises en place pour les faire cohabiter et donc pour exploiter à chaque instant toute la puissance de calcul. Ceci dit, l'article d'Anandtech semble suggérer qu'aucune cohabitation n'est possible.

        • [^] # Re: Coprocesseurs

          Posté par . Évalué à  3 .

          Ok tu parles de faire cohabiter les modèles dans un même code, pas faire cohabiter des codes MPI d'un coté et GPUs de l'autre.

          Au début des coprocs, oui les codes utilisaient uniquement les GPUs et pas ou peu les CPUs. Ce n'est plus vrai depuis 2-3 ans, les gens ont bien compris que combiner les avantages des deux était très intéressant. Y a plein de solutions qui marchent, faut surtout que les gens se mettent d'accord sur comment exposer ça aux utilisateurs, en général par un graphe de tâches.

          Pour MPI, la cohabitation avec GPU est venue très vite car les gens ont pris leur code CPU+MPI et ont remplacé CPU par GPU mais ils ont été obligés de garder MPI. Ca marchait mais ce n'était pas très optimal, notamment parce que le driver NVIDIA était tout pourri et imposait plein de copies mémoire inutiles pour aller du GPU au réseau. Ca a été corrigé depuis (et présenté comme une révolution alors que c'était surtout un bugfix) et maintenant GPU+MPI marche et est à peu près bien implémentable.

          Donc maintenant y a combinaison des trois. En gros on prend le graphe de tâches utilisé pour combiner CPU et GPU, et on le répartit sur plusieurs machines, souvent à travers MPI. C'est encore beaucoup des travaux de recherche, mais ca avance bien.

          • [^] # Re: Coprocesseurs

            Posté par (page perso) . Évalué à  3 .

            « Ok tu parles de faire cohabiter les modèles dans un même code, pas faire cohabiter des codes MPI d'un coté et GPUs de l'autre. »

            Non, précisément le contraire.

            • [^] # Re: Coprocesseurs

              Posté par . Évalué à  3 .

              Toutes ses grosses machines ont des batchs schedulers dans lesquels les utilisateurs peuvent préciser combien de coeurs de CPUs et combien de GPUs et coeurs ils veulent (voire aussi combien de mémoire). Pas vraiment de problème technique de ce coté, si ce n'est l'impossibilité de partager un GPU. On sait très bien mettre un processus utilisant deux coeurs et deux GPUs en même temps qu'un processus utilisant les autres coeurs et du MPI.

              Par contre des fois les utilisateurs ont peur de se faire marcher dessus par les voisins (par exemple si tu partages un cache ou un banc mémoire), donc ils peuvent appliquer des contraintes genre "file moi un noeud entier même si j'ai demandé qu'un seul coeur, je veux être tranquille".

              • [^] # Re: Coprocesseurs

                Posté par (page perso) . Évalué à  3 .

                Par contre des fois les utilisateurs ont peur de se faire marcher dessus par les voisins (par exemple si tu partages un cache ou un banc mémoire), donc ils peuvent appliquer des contraintes genre "file moi un noeud entier même si j'ai demandé qu'un seul coeur, je veux être tranquille".
                
                

                Ce qui explique parfois les taux de remplissage/d'utilisation "désastreux" qu'on a sur ces grosses machines (<60%).

                Ça, plus les politiques de scheduling et les pannes…

  • # Rendement

    Posté par . Évalué à  4 .

    L'efficacité [de Sequoia] est de 2 031,6 MFlops/W et on peut noter que Titan, en combinant des CPU et des GPU, arrive à offrir une meilleure efficacité (2 143 MFlops/W) énergétique que Sequoia et ses CPU développés spécialement par IBM.

    (C'est moi qui ai ajouté ce qui est en italique)

    Cette comparaison n'est pas complète, je pense. La consommation ne viens pas uniquement de la puissance de calcul. En effet la mémoire est elle aussi un gouffre de puissance sur ce genre de machines. Il y a d'autres caractéristique importantes (comme la vitesse pour sauvegarder la mémoire vive en mémoire physique par exemple) qui peuvent être importantes sans pour autant influer sur la puissance de calcul.

    Bref tout ça pour dire que si c'est en effet une caractéristique importante, ça ne suffit pas pour déduire que les GPU nVIDIA sont plus efficaces que les CPU IBM spécifiques.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Rendement

      Posté par . Évalué à  2 .

      Dans la liste des points qui peuvent influencer ce chiffre, j'ai oublié de parler du système de refroidissement qui peut beaucoup influencer ce chiffre.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Rendement

      Posté par . Évalué à  7 .

      J'imagine le type qui mesure.

      Excusez-moi, je débranche votre ordinateur deux secondes, c'est juste pour intercaler le Wattmètre.

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Rendement

        Posté par . Évalué à  1 . Dernière modification : le 14/11/12 à 11:26

        J'ai bien compris que c'était du second degré mais cela dit ils peuvent utiliser des sondes à effet Hall, qui se placent autour des câbles d'alimentation (sans avoir à les dégainer) pour mesurer le courant en se basant sur le champ magnétique produit. C'est très utilisé surtout pour les applications gourmandes en électricité (c'est certainement le cas ici).

  • # Architecture

    Posté par . Évalué à  5 .

    Est-ce qu'il vaut mieux parier sur un GPU adapté au calcul haute performance ou bien est-ce que l'approche d'Intel, consistant à privilégier la compatibilité x86, va finalement l'emporter ?

    Je pense que c'est une question de besoin. Pour certains domaines, comme la simulation nucléaire militaire, les logiciels sont déjà écris et les re-valider pour passer à une architecture CUDA peut couter chère.

    Pour des nouveaux codes la facilité de développement et le fait de ne pas avoir à faire des échanges mémoire fréquent entre la carte d'extension et la mémoire principale peut aussi donner un avantage à x86.

    Bref plus que de savoir la quelle est la meilleure architecture dans l'absolue, il me semble que c'est plus une question de cas d'usage.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Architecture

      Posté par (page perso) . Évalué à  4 .

      A savoir, il est /a priori/ très facile de porter un code sous Xeon Phi. On rajoute juste des pragma de compilation un peu comme avec OpenMP. Le fait d'avoir le même source avec ou sans Xeon Phi est vraiment un point des plus intéressants pour la grande majorité des codes universitaires.

      • [^] # Re: Architecture

        Posté par (page perso) . Évalué à  2 .

        A savoir, il est /a priori/ très facile de porter un code sous Xeon Phi. On rajoute juste des pragma de compilation un peu comme avec OpenMP. Le fait d'avoir le même source avec ou sans Xeon Phi est vraiment un point des plus intéressants pour la grande majorité des codes universitaires.

        En Théorie.

        En pratique, les accès mémoire et les transferts de données sur ce genre de systèmes coûtent un bras, voir les deux. Et le code doit être optimiser au possible pour faire le minimum de transferts possible.
        C'est impossible d'exploiter correctement ce genre d'architecture (CUDA, OpenCL, MIC, MPI, etc..) juste en ajoutant quelques pragmas ou en convertissant son code, il faut un re-design complet du programme bien souvent…

        • [^] # Re: Architecture

          Posté par (page perso) . Évalué à  3 .

          Autant, je comprends qu'il faille réarchitecturer le code pour utiliser CUDA mais je ne comprends pas pourquoi il faudrait le faire pour des Xeon Phi, en quoi sont-ils différents de processeurs x86 supplémentaires ?

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Architecture

            Posté par . Évalué à  3 .

            Je présume qu'ils n'accèdent pas à la mémoire de manière aussi simple que le processeur principal. Donc quand tu veut gérer une grande quantité de données ça risque de poser problème d'avoir a faire de gros transfert entre la mémoire principale et la mémoire du coprocesseur.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Architecture

              Posté par (page perso) . Évalué à  2 .

              Je présume qu'ils n'accèdent pas à la mémoire de manière aussi simple que le processeur principal. Donc quand tu veut gérer une grande quantité de données ça risque de poser problème d'avoir a faire de gros transfert entre la mémoire principale et la mémoire du coprocesseur.

              Exactement, les accès à la RAM du processeur principal doivent passer par le bus ( PCI-express ou autre ) ce qui est d'un facteur de plusieurs centaines de fois plus lent qu'un accès RAM classique, et d'un facteur de plusieurs de milliers de fois plus lent qu'un accès cache.

              Tous ces accés doivent etre optimisés au maximum si on ne veut pas jeter les ressources par les fenètres.

              • [^] # Re: Architecture

                Posté par . Évalué à  4 .

                Euh, je sais pas de quand date ton bus PCI, mais les ordres de grandeurs entre PCIe et RAM ne sont pas du tout aussi grands. Ce qui est compliqué c'est qu'il y a plusieurs moyens de faire les transferts, et il faut bien choisir selon la taille des données et selon si c'est la latence ou le débit qui t'intéresse. Mais quand c'est bien implémenté, le rapport des perfs entre RAM et PCIe n'est que de l'ordre de 3 ou 4 en débit et 5-10 en latence. Un GPU sur PCIe 3.0 16x, c'est de l'ordre de 10Go/s en DMA, et moins d'1 microsecondes en latence. Que NVIDIA ait implémenté ça n'importe comment est un autre problème :) Mais comme on utilise souvent des gros jeux de données, et que les gens commencent à bien savoir qu'il vaut mieux faire des gros transferts plutot que plein de petits, c'est surtout le débit qui compte.

        • [^] # Re: Architecture

          Posté par . Évalué à  3 .

          Je ne connais pas l'usage des pragma mais si c'est vraiment comme celles d'OpenMP ça permet de gagner facilement beaucoup sur des cas simple. La parallélisation des boucles ne posera problèmes que :

          • si les itérations sont interdépendantes ou utilisent des données partagées (autre que dans des cas particuliers)
          • si elles utilisent une grande quantité de données

          Mais c'est déjà pas mal.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: Architecture

            Posté par . Évalué à  2 .

            OpenMP, ca marche bien quand tu as des machines de taille raisonnable. Dès que tu passes sur des machines avec plein de coeurs et d'effets NUMA, ca devient déjà plus difficile et les gens se mettent à faire des trucs à la main pour être surs que la mémoire et/ou les threads soient au bon endroit.
            Sur Xeon Phi, c'est pas NUMA, mais y a beaucoup de coeurs, donc il va falloir que la parallélisation OpenMP scale bien, ce qui n'est pas toujours évidemment. Et comme expliqué plus haut, il y a les problèmes de mouvements de données entre hote et mémoire du Phi.

            • [^] # Re: Architecture

              Posté par . Évalué à  2 .

              Sur Xeon Phi, c'est pas NUMA, mais y a beaucoup de cœurs, donc il va falloir que la parallélisation OpenMP scale bien, ce qui n'est pas toujours évidemment.

              J'ai parlé d'OpenMP parce qu'un commentaire disait avant que ça y ressemblait, mais c'est quelque chose de spécifique fourni par Intel donc ça doit mieux se passer.

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: Architecture

                Posté par . Évalué à  1 .

                Ouais LEO est plutot du genre OpenACC. Mais ça c'est si tu fais de l'offload. Tu peux aussi faire de l'OpenMP à l'intérieur du Phi.

            • [^] # Re: Architecture

              Posté par (page perso) . Évalué à  1 .

              Des comparaisons d'utilisation du Xeon Phi commencent tout juste, certaines seront présentés bientôt publiquement, pour ceux que ça intéresseraient: http://www.lfbs.rwth-aachen.de/content/781, puis regarder le programme du second jour.

  • # Blue Waters

    Posté par (page perso) . Évalué à  4 .

    Un article complémentaire (en Anglais) publié il y a quelques jours par le chef de projet du super calculateur Blue Waters (Urbana-Champaign, Illinois) qui totalise près de 12 PetaFLOPS : http://www.ncsa.illinois.edu/News/Stories/TOP500problem/
    Il y explique en particulier pourquoi ils ont refusé de faire participer leur plateforme au Top500.

    • [^] # Re: Blue Waters

      Posté par (page perso) . Évalué à  4 .

      Même si c'est vrai que Linpack est loin d'être optimal pour mesurer les performances, y a-t'il vraiment moyen d'avoir un test meilleur ? À mon avis, il faudrait faire un test spécifique par supercalculateur qui dépendrait de son domaine d'application. Des tests pour mesurer les performances de la mémoire ou des I/O peuvent être aussi intéressant mais ils seraient autant critiqué que ne l'est Linpack aujourd'hui.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Blue Waters

        Posté par (page perso) . Évalué à  4 .

        « [y] a-t'il vraiment moyen d'avoir un test meilleur ? »

        Tout le problème est dans le « un ». Comme de nombreuses caractéristiques importent, une unique norme peut difficilement être représentative de tous les points de vue. Exactement comme si l'on mesurait un parallélépipède rectangle pour ne le décrire finalement que par R²=(l²+h²+L²) ou R = sup(l,h,L). Les uns le verraient bien plus haut que R, les autres moins large, et cætera.

  • # En vrac...

    Posté par . Évalué à  10 .

    Pour avoir eu la chance de voir une présentation de Jack Dongarra (initiateur du top500) il y a peu (et avoir visité le K-computer en même temps), j'ai appris pas mal de choses… Donc, en vrac :

    D'un point de vue historique et statistique :
    * En moyenne, le calculateur classé premier du top500 est éjecté du classement au bout de 6 ans
    * Un laptop de base (70 GFlops) aurait été 500ème en 2001 et premier en 1993 ! (essayez de faire tenir un cray dans votre sac à dos !)
    * Une tablette avec une pomme dessinée dessus développe 1 GFlops et aurait été classée 500ème en 1995 (c'était un Cray2 à l'époque )

    Pour ce qui est de Linpack :
    * La taille du système utilisé par le K-Computer était de 11 870 000 inconnues, pour un temps de résolution de 29.5 heures (10 PFlops)
    * Pour Sequoia, c'est 12 600 000 inconnues pour 23h de résolution (16 PFlops)

    D'un point de vue énergétique :
    Ce qui commence à leur poser problème maintenant, c'est de payer la facture d'électricité !
    Pour Sequoia, j'avais noté une efficacité de 1895 MFlops/W (830 pour le K-Computer, ce qui n'est pas génial, mais l'architecture est différente: sparc ici)

    L'objectif va être dans les prochaines années d'améliorer l'efficacité énergétique de ces machines (puissance de 12.7 MW pour le K-computer par exemple). Pour ces 12.7 MW, il faut compter sur une facture d'électricité de 1 million d'euros par mois environ :-)
    D'ailleurs, sur le site du K, il y a une centrale à gaz rien que pour alimenter la bestiole !

    Utilisation de la machine :
    Les japonais sont en train de réfléchir à la construction du successeur du K (objectif hexa-Flops). A priori, chaque université met dans un pot commun et le calculateur sera ouvert. Leur problème vient du fait que très peu de codes sont capables de tourner sur la machine complète (problème de scaling): l'objectif est donc de définir une architecture suffisamment souple pour contenter tout le monde.

    A noter aussi un changement de mentalité : l'objectif pour le K était d'être premier au top500, ce n'est plus le cas pour la future machine dont l'objectif est d'être utilisable en pratique.

    J'ai 2-3 photos si certains sont intéressés.

    • [^] # Re: En vrac...

      Posté par . Évalué à  4 .

      L'objectif va être dans les prochaines années d'améliorer l'efficacité énergétique de ces machines (puissance de 12.7 MW pour le K-computer par exemple). Pour ces 12.7 MW, il faut compter sur une facture d'électricité de 1 million d'euros par mois environ :-)
      D'ailleurs, sur le site du K, il y a une centrale à gaz rien que pour alimenter la bestiole !

      Il faut noter que la consommation ne vient pas uniquement de la consommation électrique des composant mais aussi du système de refroidissement. De ce que je crois en savoir, aujourd'hui, si on dit qu'une de ces machines consomme 1MW, il y a grosso modo 50% qui est consommé par le système de refroidissement. L'un des enjeux est d'arriver à améliorer cela. Les techniques vont être de rapprocher le watercooling des composant pour arriver à faire ce qui est fait sur les machines de particulier, c'est à dire que les CPU auront un slot dans le quel on ferra passer de l'eau. Cela pourrait, à moyen terme fortement la puissance consommer pour les systèmes de refroidissement.

      Bien sûr ce n'est pas pour ça que les machines consommeront moins, elles seront plus puissantes et auront un meilleur rendement.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: En vrac...

        Posté par . Évalué à  4 .

        50%, cela date de l'époque ou les rac de PC était dans des salles climatisé à 12°C.

        Il me semble que pour OVH, c'est 7% (watercooling + effet cheminé), par exemple.

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

    • [^] # Re: En vrac...

      Posté par (page perso) . Évalué à  5 .

      essayez de faire tenir un cray dans votre sac à dos !

      A défaut on peut le faire tenir dans un bureau…
      http://www.paulla.asso.fr/galeries/cray-cx-1

      Cette machine serait dans le top500 en juin 2007 ! Elle a une puissance d'un peu plus de 4Tflops en simple precision

      Aujourd'hui on fait tenir 4 Tflops en double precision dans une grosse tour genre Dell T620

      Demain dans un portable…

    • [^] # Re: En vrac...

      Posté par (page perso) . Évalué à  2 .

      A noter aussi un changement de mentalité : l'objectif pour le K était d'être premier au top500, ce n'est plus le cas pour la future machine dont l'objectif est d'être utilisable en pratique.

      Quand on voit combien coûtent ces joujoux et combien ils coûtent par heure, je crois qu'on pourrait aussi faire des statistiques très intéressantes sur le coût d'un run du benchmark en € et en W!

      Si j'avais payé des dizaines de millions de dollars pour un supercalculateur, ça me tracasserait d'apprendre qu'il a passé les 3 dernières semaines à lancer et relancer le benchmark après moultes optimisations pour avoir une bonne note au concours de la plus grosse.

      • [^] # Re: En vrac...

        Posté par (page perso) . Évalué à  2 .

        J'imagine que le coût du benchmark doit être pris en charge, au moins en partie, par le constructeur. Ça fait toujours une bonne pub de pouvoir annoncer avoir construit le n° X du Top 500.

        Accessoirement, il doit y avoir plusieurs essais, à cause des pannes. Sur ce genre de machines, les pannes sont fréquentes et normales.

        • [^] # Re: En vrac...

          Posté par . Évalué à  4 .

          Ça fait toujours une bonne pub de pouvoir annoncer avoir construit le n° X du Top 500.

          Ça fait aussi une bonne pub pour le client (« Venez travaillez avec nous on a du super matos ! »).

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: En vrac...

        Posté par (page perso) . Évalué à  5 .

        Puis c'est un moyen intéressant de vérifier que la machine fonctionne bien comme prévu (il faut bien tester les machines avant de les utiliser industriellement non ?)

  • # Linux pris au sérieux?

    Posté par . Évalué à  -3 .

    En terme de système d'exploitation, la domination écrasante de Linux se maintient et, même, se renforce encore un peu plus. En un an, on est passé de 457 machines (91,4 %) à 469 machines (soit 93,8 % du classement).

    Mais il leur manque Steam cf ce commentaire de Zenitram! :)

  • # manque une citation de l'ancien nom "MIC"

    Posté par . Évalué à  4 .

    Le nom "Xeon Phi" ne remplace pas Knights Corner mais plutot le nom officieux "MIC" (many integrated core). Knights Corner est le codename de la génération actuelle du Xeon Phi, comme Sandy-Bridge pour les Xeon ou Ivy-Bridge pour les Core i7.

  • # Utilité ?

    Posté par . Évalué à  1 .

    Je ne nie pas l'utilité des systèmes moins puissants pour la recherche ou la conception industrielle, mais je me pose des questions quant à l'intérêt de la course au Top500. J'ai le sentiment que celle-ci s'apparente à une vitrine pour institutions, pays ou grosses entreprises.

    Parce qu'en dehors de la recherche sur les armes nucléaires, la cryptographie et la climatologie, dont on entend parler si souvent, quel peut être l'intérêt d'une telle débauche de puissance de calcul ? D'ailleurs, quelles ont été les avancées scientifiques concrètes réalisées par de telles machines par le passé ?

    Enfin voilà, si quelqu'un pouvait m'éclairer sur le sujet. Merci.

    • [^] # Re: Utilité ?

      Posté par . Évalué à  1 .

      Pour troller en ces temps de crise :

      Le calcul intensif (HPC) est à l'image du CERN. Il fait l'objet d'une politique de projets (au niveau national et européen) où se côtoient des acteurs scientifiques, industriels et politiques. Avec les résultats que l'on connait : grande dépense publique, grandes retombées financières (industriels) ou subventions déguisées (Bull), et faibles avancées scientifiques au final quoiqu'on en dise (car les progrès technologiques induits sont l'oeuvre d'une gabegie au regard des investissements consentis, alors que des dépenses ciblées auraient été plus "rentables").

      Mais ça fait tout de même marcher une partie de l'économie (surtout celle des fondeurs de puces étrangères).

      My 2 cents :)

    • [^] # Re: Utilité ?

      Posté par . Évalué à  6 .

      Que tu dises "en dehors des armes nucleaires, je vois pas l'interet", OK. En dehors la crypto, admettons. Par contre la climato c'est utile pour la société. Et les prévisions météo a plus court terme sont également capables d'utiliser des puissances de calcul colossales, ils suffit d'augmenter la précision et/ou la durée de prédiction. Il y a plein d'applis qui sont capables d'utiliser de telles puissances sans forcément avoir des buts malveillants.

      Ce matin, à supercomputing, il y avait par exemple une présentation parlant de simulations du cerveau humain (http://sc12.supercomputing.org/schedule/event_detail.php?evid=inspkr103). En gros, pour savoir si on comprend bien comment ca marche (puis essayer de le guérir), on va simuler ce qu'on a compris. Sauf qu'il faut un exaflop/s pour faire ça apparemment, donc 100 fois les plus gros supercalculateurs actuels…

      Les avancées concrètes dues au HPC, y en a partout dans la société moderne, vu que la simulation numérique est partout:
      * Les prévisions météo sont passées de 5 à 7 il y a quelques années
      * On sait faire des batiments antisismiques (pas facile de tester grandeur nature, la simu numérique est la seule solution pour ça)
      * On concoit des voitures plus solides en les modélisant numériquement (et en les crash-testant numériquement)
      Tous les trucs que les ingénieurs faisaient avant en resolvant des grosses équations qui font mal à la tête, en physique mais pas que…

      • [^] # Re: Utilité ?

        Posté par . Évalué à  2 .

        • Les prévisions météo sont passées de 5 à 7 il y a quelques années
        • On sait faire des batiments antisismiques (pas facile de tester grandeur nature, la simu numérique est la seule solution pour ça)
        • On concoit des voitures plus solides en les modélisant numériquement (et en les crash-testant numériquement)

        Même pour des choses qui paraissent plus simples. Quasiment toute création industrielle passe par de la simulation numérique.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Utilité ?

          Posté par . Évalué à  1 .

          Oui, je suis tout à fait d'accord.

          Cependant cela amène la question suivante : puisque la simulation numérique est devenue indispensable dans les conception industrielle, est-il pertinent de chercher à exploiter de tels monstres de calculs d'une part, et ne vaut-il pas mieux disposer de sa propre unité de calcul plutôt que de devoir s'en remettre à une entité extérieure (avec des délais et des coûts qui peuvent s'avérer problématiques dans le cadre d'un projet industriel) ?

          • [^] # Re: Utilité ?

            Posté par . Évalué à  3 .

            Les délais ca s'anticipe. Les industriels savent bien à l'avance quand ils vont besoin de ressources de calcul.
            L'avantage des gros calculateurs, c'est un peu comme le cloud, tu factorises plein de couts par rapport à avoir plein de petits calculateurs partout. Un industriel qui a besoin d'un teraflop/s 10 semaines par an, aucune utilité d'avoir chez lui un calculateur. Seuls les gros (comme Total ou météofrance chez nous) qui font des calculs tout le temps peuvent justifier un tel investissement.

            • [^] # Re: Utilité ?

              Posté par . Évalué à  1 .

              Un industriel qui a besoin d'un teraflop/s 10 semaines par an, aucune utilité d'avoir chez lui un calculateur.

              Au contraire, vu que les dernières cartes graphiques professionnelles de quelques centaines d'euros atteignent déjà le teraflops (en double précision), il parait plus intéressant pour un tel industriel d'avoir son propre calculateur.

              ou météofrance chez nous

              Pourrais-tu nous dire si Météo France se sert de machines du top500 pour établir ses prévisions météo (je ne parle pas de climatologie ou de recherche de pointe) ou si au contraire elle exploite des systèmes moins puissants.

              • [^] # Re: Utilité ?

                Posté par . Évalué à  2 .

                Si le but est d'avoir le résultat le plus rapidement possible, tu utilises mieux tes ressources à avoir un serveur de la mort qui est blindé en permanence. Quand tu as besoin de ta machine tu as ton résultat en 24h au lieu de qq semaines.

                Il parait qu'il y a un paquet de cluster de machine qui n'ont quasiment pas servi faute de l'administration système qu'il faut avec (dans les université par exemple). L'argent aurait du rester dans la division dédié et l'université aurait pu louer son temps de calcul à la demande. Rien n’empêche d'avoir des clusters de 4 machines pour faire des tests de mise au point.

                "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

              • [^] # Re: Utilité ?

                Posté par . Évalué à  4 .

                Au contraire, vu que les dernières cartes graphiques professionnelles
                de quelques centaines d'euros atteignent déjà le teraflops (en double
                précision), il parait plus intéressant pour un tel industriel d'avoir
                son propre calculateur.

                Pour quelques centaines d'euros, t'as des cartes de gamers, pas des cartes Pro. Pour le HPC, c'est bof, par exemple parce que la mémoire n'est pas ECC. On prend des cartes pros ou spécialisées en HPC, mais ca coute beaucoup plus chers.
                En double-précision, il n'y a que les toutes dernières cartes qui s'approchent du teraflop/s (celles annoncés à SC12 en gros). Elles vont couter plus de 2000€ que ce soit chez Intel, NVIDIA ou AMD. Et tout ça, c'est du teraflop/s théorique. La plupart des vrais applis n'en exploitent qu'une toute petite part…

                Pourrais-tu nous dire si Météo France se sert de machines du top500 pour
                établir ses prévisions météo.

                Meteofrance utilise a priori actuellement un NEC SX9 acheté en 2009 dont la puissance est de l'ordre de 50 Tera si je me souviens bien. Mais il n'a pas l'air d'avoir jamais été dans le top500.

                Brice

      • [^] # Re: Utilité ?

        Posté par . Évalué à  3 .

        Ma question ne portait pas sur l'utilité de la simulation numérique, que je ne remets pas en cause, mais de celle de développer des machines aussi puissantes.

        • Météo France fait-elle ses prévisions météo en se servant de systèmes du top500 ou au contraire de systèmes moins puissants mais plus adaptés à ses besoins (en utilisant ses propres techniciens et ingénieurs, et sans avoir à partager du temps de calcul avec d'autres entités extérieures) ?

        • La conception de bâtiments parasismiques ou celle de voitures plus sûres n'ont pas attendu que l'on ait construit des machines "pétaflopiques".

        Il me semble en fait que beaucoup de ces domaines de conception peuvent être couverts par des machines du niveau téraflopique (une capacité de calcul en double précision atteinte par les dernières générations de carte graphiques professionnelles). Et qu'au final, en dehors de quelques secteurs de pointe (crypto/nucléaire/climato), les machines du niveau du top500 relèvent davantage de l'expérimentation et de la recherche/développement des technologies informatiques.

        • [^] # Re: Utilité ?

          Posté par (page perso) . Évalué à  7 .

          La conception de bâtiments parasismiques ou celle de voitures plus sûres n'ont pas attendu que l'on ait construit des machines "pétaflopiques".

          La cryptographie ou la recherche nucléaire non plus. Ce n'est pas parce qu'on pouvait faire avant sans que ça n'aide pas à améliorer les choses.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Utilité ?

            Posté par . Évalué à  1 .

            Ce n'est pas parce qu'on pouvait faire avant sans que ça n'aide pas à améliorer les choses.

            C'est vrai, mais dans quelle mesure cela peut-il améliorer les choses ?

            Il y a quelques années Météo France est passée de la prévision à 5 jours à la prévision à 7 jours. Pourquoi n'avoir pas poursuivi avec la prévision à 9 jours ? S'agit-il d'une limitation volontaire (absence d'intérêt commercial pour de telles prévisions) ou involontaires (limitation du modèle, capacité de calcul insuffisante et coût prohibitif, ou conséquence de la théorie du chaos) ?

            • [^] # Re: Utilité ?

              Posté par . Évalué à  5 .

              On peut trouver certaines informations sur le site de Météo-France, en particulier concernant l'indice de confiance, c'est-à-dire la capacité des modèles à donner des résultats similaires (fort indice de confiance) ou pas (faible indice de confiance) pour les prévisions à J+4, J+5 et J+6, J+7.

              Concernant les moyens de calculs, la page en question indique qu'il s'agit d'un NEC SX-9 sans qu'on en connaisse le nombre de nœuds (le graphique semble indiqué quelque chose comme 20 TFLOPS).

              À noter, que la semaine dernière, Bull a annoncé une commande de Météo-France pour un nouveau super calculateur (1 PFLOPS dans un premier temps puis 5 PFLOPS en 2016).

        • [^] # Re: Utilité ?

          Posté par (page perso) . Évalué à  5 .

          Quel climat en 2100 ?

          Il faut repartir depuis 1950, faire tourner les modèles atmosphériques et océanographiques avec recalage jusqu'à nos jours puis se lancer dans le futur sans filet… Si on veut être précis, faut tenir compte de tous les ouragans… Des bases de données, une maille de calcul très fine, des modèles de plus en plus complexe (exemple, comment l'océan absorbe le CO2).

          En plus du réchauffement atmosphérique, il y a l'énorme problème de la montée des eaux !

          -> à ma connaissance, on ne sais pas encore faire

          Je vous invite a aller faire un tour sur le site de PRACE et à lire le rapport scientifique que l'on trouve sur la page http://www.prace-project.eu/PRACE-Scientific-Annual-Report

          Un exemple de succès est une modélisation fine de la turbulence qui devrait permettre à terme d'économiser 2% de carburant sur les avions et les bateaux. J'ai pris cet exemple car je n'y comprends rien en bio et c'est pas du nucléaire ;-)

          PS : regardez la liste des pays dans PRACE, on voit que l'UE est à géométrie variable mais se met en place petit à petit dans tous les domaines. Bien sur les suisses sont dedans.

          • [^] # Re: Utilité ?

            Posté par . Évalué à  3 .

            Un exemple de succès est une modélisation fine de la turbulence qui devrait permettre à terme d'économiser 2% de carburant sur les avions et les bateaux.

            Les turbulences générées par la surface des avions ont été étudiées il y a quelques années déjà. Depuis les constructeurs se sont tournés vers des solutions biomimétiques basées sur la peau du requin qui comporte des rainures. Des résultats significatifs ont ainsi été obtenus, même si cela a fait apparaître d'autres difficultés telle que la durabilité face aux intempéries et à l'usure.

            On peut dès lors se demander si ces 2 % sont atteignables (et 2 % par rapport à ce qui se fait déjà ou bien par rapport à une surface "lisse" ?), s'ils sont persistants dans le temps (usure, entretien régulier indispensable) et s'ils ne seront pas réduits par les procédés technologiques utilisés (l'application d'un film sur toute la surface de l'avion, crée un poids supplémentaire qui augmente la consommation globale de l'avion).

            Au delà de ces questions, même si 2 % c'est toujours bon à prendre, ça parait finalement peu. Qui plus est, cela laisse à penser qu'on s'est beaucoup rapproché de la réponse optimale et que peu de progrès peuvent encore être espérés sur ce point, malgré toute la puissance de calcul dont on pourrait disposer.

            • [^] # Re: Utilité ?

              Posté par (page perso) . Évalué à  2 .

              Au delà de ces questions, même si 2 % c'est toujours bon à prendre, ça parait finalement peu.

              Vu ce que consomme un avion pour un trajet, 2% représente pas mal de litres de kérosène et étant donné le trafic aérien actuel, si tous les avions consommaient 2% en moins ça serait significatif. Après il est vrai que de faire mieux sera délicat, à moins de trouver des architectures totalement différentes (ce qui semble là encore difficile à faire mieux).

              • [^] # Re: Utilité ?

                Posté par . Évalué à  3 .

                Sachant que le trafic aérien augmente de 4% par an, un gain de 2% (en supposant qu'on arrive à l'appliquer à la totalité de la flotte mondiale) sera effacé en à peine 6 mois.
                Il faudrait atteindre un gain d'au moins 4% par an pour simplement maintenir la consommation au niveau actuel.

              • [^] # Re: Utilité ?

                Posté par (page perso) . Évalué à  2 .

                Bin 2% de beaucoup, ça ne reste que 2%… Autant dire que ce n'est pas ça qui va changer la face du monde. Si le trafic aérien augmente de 4% par an, que tu améliores de 2% une partie des avions, tu auras juste décalé ton augmentation de 2 ou 3mois.

            • [^] # Re: Utilité ?

              Posté par . Évalué à  2 .

              On peut dès lors se demander si ces 2 % sont atteignables (et 2 % par rapport à ce qui se fait déjà ou bien par rapport à une surface "lisse" ?), s'ils sont persistants dans le temps (usure, entretien régulier indispensable) et s'ils ne seront pas réduits par les procédés technologiques utilisés (l'application d'un film sur toute la surface de l'avion, crée un poids supplémentaire qui augmente la consommation globale de l'avion).

              Si on a les bons modèles ça se simule. Avec ça et de la programmation linéaire tu doit pouvoir estimer la surface optimale qui doit être recouverte pour réduire les coûts globales (parce que c'est ça qui est rechercher la planète c'est bien mais hors du greenwashing les entreprises s'en foutent). Je ne sais pas à quel point la PL est parallélisable, mais il faut faire le calcul sur un certains nombres de modèles (outre Airbus et Boeing, les canadaires et autre types d'avions peuvent être intéressés (et avoir les moyens)).

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: Utilité ?

        Posté par . Évalué à  0 .

        Ben pour simuler le cerveau on prend les heureux gagnants du Top 500 et on les branche en calcul parallèle ? :D
        --> []

    • [^] # Re: Utilité ?

      Posté par (page perso) . Évalué à  3 .

      Je me posais aussi la question. Je dirais que ça sert partout où il y a des équations différentielles infernales, donc dans un peu tous les domaines de la physique. Si on peut éviter d'attendre une semaine le résultat d'un calcul,c'est pas mal. Surtout si c'est pour s'apercevoir qu'il est faux…

      • [^] # Re: Utilité ?

        Posté par . Évalué à  1 .

        Oui, mais d'un autre côté, pour bénéficier d'une fenêtre de calcul (se voir octroyer une date et une durée pour pouvoir faire faire les calculs sur ces machines), il faut peut-être attendre quelques semaines (en mettant de côté le financement, la rédaction d'un dossier, le passage devant une commission, la paperasse administrative, …).

        • [^] # Re: Utilité ?

          Posté par . Évalué à  2 .

          En ayant un gros calculateur petaflopique plutot que plein de teraflopiques, tu factorises plein de couts.

        • [^] # Re: Utilité ?

          Posté par . Évalué à  2 .

          Ce que tu décris est plus un problème administratif et de scheduling, qu'un problème technique. Un gros centre de calcul peut aussi prévoir un machine plus petite alloué aux calculs rapides pour éviter d'attendre la disponibilité de la grosse machine (privilégier une latence faible vs un gros débit). Il peut aussi faire en sorte d'avoir plusieurs machines.

          En tout cas, c'est amusant de penser à l'allocation de temps de calcul sur plusieurs superordinateur, comme on pourrait penser au scheduling de cpu fait par un OS :)

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: Utilité ?

          Posté par (page perso) . Évalué à  8 .

          Pour lancer ton calcul sur une machine PRACE, je pense que tu peux préparer ton dossier 1 an à l'avance… D'un autre coté, il faut quand même que ton sujet soit validé et que ton code tourne sur 10000 coeurs ! Si c'est pour faire tourner un code sur 100 coeurs, les machines de GENCI ou les méso-centre suffisent.

          Bref, il y a un gros temps de préparation ou d'ailleurs, tu peux te faire aider par le personnel du centre. Tu ne prépare pas un run sur 20000 coeurs de 3 semaines en quelques jours généralement (~ 10 millions d'heure de calcul == 1150 ans de calcul séquentiel).

          Derrière, c'est le contribuable qui finance donc un peu de respect s'impose.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.