• # Un truc super moderne...

    Posté par  (site Web personnel) . Évalué à 10.

    ... comme par hasard... le Fortran ?

    Enfin, je dis ça, je ne sais pas.
  • # Comment font-ils ?

    Posté par  . Évalué à 3.

    J'aimerais bien comprendre comment ils font pour faire leurs calculs. Déjà je vois qu'ils font du maillage. Mais après, en quoi consistent leurs calculs ?


    PS: j'aurais bien aimé que le journal soit un peu plus clair : au lieu de copier/coller une url, un résumé n'aurait pas été de trop.
    • [^] # Re: Comment font-ils ?

      Posté par  (site Web personnel) . Évalué à 10.

      Déjà, l'atmosphère est maillée en carrés de tailles variables (plus fine sur les région intéressante, en ce qui nous concerne, l'europe et la France).

      Les relevés météo des stations dispatchées partout en France et dans le monde apportent les données nécessaires aux équations (des conditions initiales) : pression, température, humidité, force et direction du vent, etc...

      Ensuite ils utilisent des équations (généralement différentielles) qui sont discrétisées pour s'adapter au maillage, et on mouline le tout (en gros). Cf
      http://fr.wikipedia.org/wiki/Météorologie#Comportement_.C3.A0_grande_.C3.A9chelle
      et
      http://fr.wikipedia.org/wiki/Équations_primitives_atmosphériques
      http://fr.wikipedia.org/wiki/Prévision_météorologique

      Reste, qu'en pratique, c'est bien plus compliqué que cela, étant donné que les algo réinjectent les dernières mesures réalisées (elles ne sont pas toutes réalisées au même moment..) pour corriger le modèle en temps presque réel, etc...
      • [^] # Re: Comment font-ils ?

        Posté par  . Évalué à 4.

        Déjà, l'atmosphère est maillée en carrés de tailles variables


        s/carrés/cubes/
        • [^] # Re: Comment font-ils ?

          Posté par  (site Web personnel) . Évalué à -1.

          Je ne bosse pas chez météo france, mais il se peut aussi que l'atmosphere soit bien maillée en carrés. En effet, ce qui compte c'est la météo au sol, pas a 3 km au dessus.
          • [^] # Re: Comment font-ils ?

            Posté par  . Évalué à 9.

            ce qui compte c'est la météo au sol, pas a 3 km au dessus

            deux choses pour contredire ce que tu viens d'affirmer :
            - météo france ne fait pas que le prévisions météo pour la télévision, mais aussi (et surtout) pour les professionnels qui dépendent énormément du temps qu'il va faire, et parmi ceux-ci, on trouve toute l'aviation (civile, militaire, générale)
            - ensuite pour calculer des prévisions du temps au sol, il faut prévoir aussi comment ça va se passer un peu plus haut

            Voilà voilà ...
    • [^] # Re: Comment font-ils ?

      Posté par  . Évalué à 7.

      Simulation numérique à partir de modèle je pense, genre on connait l'état d'une maille à un temps t avec plein d'infos, l'état des mailles d'à côté a un temps t, et on calcule l'état à un temps t+1 de la maille à partir des équations numérique du modèle qui décrit l'évolution du système. Et des propriétés de la maill aussi, genre si c'est une montagne ou l'océan avec plein d'évaporation.

      Me demande rien sur la tête du modèle, c'est pas trop mon domaine, ce que je sais c'set que Navier-Strokes c'est des équations qui reviennent souvent dans ce genre de travaux, et qu'on sait pas les résoudre analytiquement, donc en général on utilise des approximations numériques.

      Hop des références wikipédiennes en vrac:

      http://fr.wikipedia.org/wiki/M%C3%A9t%C3%A9o

      http://fr.wikipedia.org/wiki/Pr%C3%A9vision_m%C3%A9t%C3%A9or(...)

      http://fr.wikipedia.org/wiki/Pr%C3%A9vision_num%C3%A9rique_d(...)

      http://fr.wikipedia.org/wiki/%C3%89quations_primitives_atmos(...)

      http://fr.wikipedia.org/wiki/%C3%89quations_de_Navier-Stokes
      • [^] # Re: Comment font-ils ?

        Posté par  . Évalué à 3.

        C'est une methode de simulation assez classique

        En gros tu prend ton equation differentielle, tu la discretise c'est à dire que tu ecrit les derivée comme
        f'=((x+h)-f(x))/h
        Tu ecris toutes les derivées dont tu as besoin comme ça.
        h c'est le pas de ton reseaux

        Au final tu as des equations qui donnent l'etat à l'iterations suivante en fonction de l'état des voisins. ( et d'un nombre d'iteration précédente qui dépend de l'ordre de l'équation ).
        Souvent formuler correctement l'équation est un sacré boulot. Compte pas mal de temps au tableau noir et au papier avant d'envisager ecrire la moindre ligne de code...

        Tu remplis ta grille avec des mesures et tu moulines.
        En gros tu te contente de sommer des enormes tableau en imbriquant tout plein de boucle bref tout ce qu'il faut pour avoir un code qui tourne vite..

        J'imagine qu'après a la meteo ils sont plus malin, par exemple en travaillant dans l'espace de fourrier où d'autre astuce pour eviter que le systeme diverge trop vite...
        • [^] # Re: Comment font-ils ?

          Posté par  . Évalué à 1.

          tiens depuis Lorentz je croyais qu'un syème chaotique n'était pas si linéaire, principalement pour ses conditions sensibles initiales
          • [^] # Re: Comment font-ils ?

            Posté par  . Évalué à 3.

            J'ai beau relire son message, je ne vois pas où il a parlé de problèmes linéaires ;-)
            • [^] # Re: Comment font-ils ?

              Posté par  . Évalué à 1.

              et que pense tu alors alors de la condition déterministe qui y est absente ? est ce si prévisible que cela ? il est pourtant plus qu'évident que depuis de longues années les équipes de prévisions météo sont équipées des calculateurs les plus puissants et qui pourtant ne permettent pas de prévoir une modification climatique parce qu'un petit "diablotin" (cf David Ruelle) est à l'origine d'une modiification climatique.


              "Une cause trés petite qui nous échappe, détermine un effet considérable que nous ne pouvons pas ne pas voir et alors nous disons que cet effet est dû au hasard"

              Poincarré
          • [^] # Re: Comment font-ils ?

            Posté par  (site Web personnel) . Évalué à 2.

            Non, depuis on a prouvé que ce n'était valable que pour des systèmes à quelques variables, mais dès qu'on passe à une plus de quelques dizaines de variables, l'"effet papillon" disparaît.

            Une version mise à jour de l'article publié dans Pour la Science, il y a quelques années :
            http://interstices.info/display.jsp?id=c_19155

            Un article plus solide :
            http://smf.emath.fr/Publications/Gazette/2001/90/smf_gazette(...)

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # concours de b*te

    Posté par  (site Web personnel) . Évalué à 1.

    Le SX-8R actuellement installé chez Météo-France est constitué de 32 n½uds de huit processeurs chacun. Chaque processeur (2,2 GHz) est capable de traiter 35,2 milliards d’opérations informatiques (Gigaflops) par seconde, soit pour Météo-France une capacité totale de 1 Téraflops.

    C'est vraiment pas si impressionnant que ça. Si on prend un Xeon quad-core à 3GHz , chaque coeur peut effectuer 3e9 * 4 operations (en double precision) par seconde, fois 4 coeurs et ça fait 48GFlops par cpu, avec une vingtaine d'entre eux on atteint le tflop
    • [^] # Re: concours de b*te

      Posté par  (site Web personnel) . Évalué à 4.

      La différence est qu'ici la machine est vectorielle, la comparaison est donc délicate... Une opération vectorielle à tendance à faire un peu plus de chose qu'une opération classique (même en double précision....)

      De plus l'article parle aussi de la bande passante avec la mémoire qui serait énorme, mais vu le niveau de détails donnés on ne peut pas en tirer grand chose.
    • [^] # Re: concours de b*te

      Posté par  . Évalué à 5.

      En moyenne, l'ipc (instruction per clock) d'un Xeon n'est pas 4. J'avais lu 1.9 pour un athlon. Un Xeon doit à peine sortir une multiplication par cycle en double (64 bits) même en SSE2.

      Les SX8 disposent d'unité vectoriel. Genre il traite une dizaine de nombre à la fois. vu le rapport entre 2.2 et 35.2, cela tombe pile poil sur 16. Donc les vecteurs font 16 nombres de 64 bits. C'est déjà bien plus que ce que permet un xeon en SSE2.

      Selon la doc Nec, le SX8R dispose manipule des vecteurs de 4 nombres sur 4 pipelines (d'ou le x16), par contre un dessin montre seulement 2 pipes avec multiplication. Donc, on doit être à 17.6 MMACS flottant ce qui est déjà énorme. De plus, le cpu dipose de 70 Go/s de bande passante.

      Le xeon devrait doubler sa puissance de calcul pour se rapprocher (genre 2 unités de multiplication au lieu d'une et augmenter sa bande passante mémoire)

      "La première sécurité est la liberté"

      • [^] # Re: concours de b*te

        Posté par  (site Web personnel) . Évalué à 2.

        Bah oui mai un teraflop ça reste une puissance très modeste de nos jours.
        Certes en 2009 il devrait être plus puissant mais bon...
      • [^] # Re: concours de b*te

        Posté par  (site Web personnel) . Évalué à 1.

        Un Xeon doit à peine sortir une multiplication par cycle en double (64 bits) même en SSE2.

        La génération des core 2 duo (et leurs versions xeon) permet 4 flop/cycle/core (probablement moitié multiplication moitié addition, j'ai pas vérifié) en double précision (8 en simple précision), bien entendu en SSE2. Ca fait quand même 12 Gflops/core, ou 48 pour un quad core. c'est quand même pas mal, et pas forcement plus difficile à exploiter efficacement qu'un cpu qui ne manipule que des vecteurs de taille 16 ! Pour la bande passante certes il ne fait sans doute pas le poids, mais je voulais juste souligner qu'il n'y avait pas forcément de quoi s'extasier devant les gigaflops de ces machines ordinosauresques
        • [^] # Re: concours de b*te

          Posté par  . Évalué à 3.

          En pratique, entre la puissance théorique d'un pentium en règle générale, et la performance réelle, l'écart est généralement assez grand. Et effectivement, avoir un IPC de 2 sur pentium, ou 2.5, c'est déjà pas mal du tout (voire carrément très bien).

          Sur Itanium2, où tout est in-order sauf certains accès mémoire (et donc où tout est fait par le compilo), on réussit à avoir certains types de codes avec un IPC de 4 voire 4.5 sur les 6 théoriques, et on est extrêmement content quand ça arrive. Et pourtant, contrairement au pentium, dans ce cas précis, on comprend comment ça fonctionne (à peu près ;-) ).

          Je suis justement en train de bosser sur Xeon/Core 2 duo. C'est sûr, ça va vite. Mais on est très loin de la performance crête.
          • [^] # Re: concours de b*te

            Posté par  (site Web personnel) . Évalué à 2.

            Je ne sais pas trop comment tu comptes les IPC avec des instructions "petit-vectorielles" comme SSE, mais si tu lances les bench de atlas (genre celui sur le produit matrice-matrice, xdl3blastst), tu devrais voir des chiffres qui ne sont pas loin de 75% des 12 gflops que j'ai annoncé (j'ai pas de c2duo sous linux pour vérifier). Par ex. si je le lance sur un vieux xeon pentium 4 à 3GHz, qui a 5 ans d'age, il est à 4400 GFlops en crete (peak: 6GFlops). Comme les c2duo ont doublé les perfs SSE tu devrais voir pas loin de 9gflops, ou mieux.
            • [^] # Re: concours de b*te

              Posté par  . Évalué à 2.

              Lorsque j'utilise la MKL (biblio propriétaire d'intel pour les maths) avec un produit de matrices carrées denses, j'ai quelque chose comme 97 % des performances crête. Mais je ne pense pas que ce soit vraiment significatif de codes de la vie réelle (en fait j'en suis même sûr).
              • [^] # Re: concours de b*te

                Posté par  (site Web personnel) . Évalué à 2.

                Et quelles sont elles ces performances cretes en termes de gflops ?

                C'est sur si tu veux utiliser efficacement le sse il ne pas compter sur le compilateur, il faut explicitement ecrire le code "vectorisé", et ça n'est surement pas evident quand ton code à la base manipule des matrices creuses. Mais ça reste certainement plus simple d'écrire du code adapté pour des vecteurs de taille 2 que pour des vecteurs de taille 16 comme sur la nec
                • [^] # Re: concours de b*te

                  Posté par  . Évalué à 3.

                  Pour te donner un ordre d'idée, sur Itanium 2, les perfs crête se situent aux alentours de 6.4 GFLOPS, et une DGEMM tourne autour de 6.2 GFLOPS quelle que soit sa taille, et quel que soit le nombre de procs (au moins jusqu'à 8) avec la MKL. ATLAS fait un peu moins bien (je n'ai pas les chiffres).

                  Pour info, les noyaux de calcul de la MKL sont faits main (ils y fourrent de l'ASM tout partout) pour avoir la meilleure perf possible.

                  Sur Xeon je n'ai pas encore effectué toute ma batterie de tests, donc je préfère m'abstenir de commenter.

                  Quant à ta remarque sur les compilateurs, les intrinsics marchent pas si mal à ce que j'ai vu, vu qu'en fait ça revient juste à avoir une interface C au-dessus des instructions ASM. Pour les vecteurs de taille 16, je vois pas en quoi ce serait plus simple, étant donné le nombre de mailles manipulées simultanément.
                  • [^] # Re: concours de b*te

                    Posté par  (site Web personnel) . Évalué à 2.

                    oui j'utilise aussi les intrinsics, ça a l'immense avantage de ne pas avoir à reflechir au choix des registres, par contre la contrainte principale du sse (ou de l'altivec) c'est l'alignement des données, et si ça n'est pas prévu dés le départ c'est le casse tête garanti.
        • [^] # Re: concours de b*te

          Posté par  . Évalué à 3.

          Si on compte juste la multiplication, c'est 2 fmul/cycle/core en 64 bits. Je n'ai pas vérifié mais il est tout a fait possible que les opérations 64 bits soient plus que 2x plus lente que les opérations 32 bits.

          C'est vrai que le SX-8 pourrait se faire rattraper mais il faudrait douler les ressource mathématique du x86 (genre 4 controleurs mémoire et 2 unités vectoriel pour les multipliations).

          Et puis ce genre de processeurs disposent de moyen de communication trés rapide. Il faut en général des controleurs de réseau et autres assez complexe. (sur les ascii d'IBM, il y avait 3 réseau, un arbre, un mesh à 6 branche et un truc que j'ai oublié :)

          "La première sécurité est la liberté"

  • # Pourquoi ne pas utiliser de processeurs graphiques ?

    Posté par  (site Web personnel) . Évalué à 2.

    Certains intervenants ici, et je pense en particulier à nicO, on déjà relevé qu'un processeur pouvait calculer 5 Gflops, tandis qu'un processeur graphique pouvait atteindre 50 Gflops.

    J'ai trouvé ça :
    http://www.cg.informatik.uni-siegen.de/data/Publications/200(...)
    Ya peut être mieux.

    Mais c'est dommage que ce ne soit pas plus utilisé.
    20 cartes --> 1 TeraFlops

    A 500 ¤ la carte, c'est pas cher...

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Pourquoi ne pas utiliser de processeurs graphiques ?

      Posté par  . Évalué à 3.

      cf mes interventions dans le wiki de lisaac... :)

      "La première sécurité est la liberté"

    • [^] # Re: Pourquoi ne pas utiliser de processeurs graphiques ?

      Posté par  . Évalué à 2.

      Le problème c'est que pour tirer parti des GPU, il faut avoir des problèmes « intrinsèquement » parallèles, sans trop de synchro. Il faut aussi un problème assez gros pour recouvrir la latence due au passage des données sur le bus. Par contre je pense que le rapprochement CPU/GPU qui va être très rapidement fait [1] permettra à terme de mieux distribuer les tâches et de mieux exploiter le parallélisme lorsqu'il y aura lieu de le faire.

      [1] AMD + ATI par exemple, ça va très vite donner des GPU+CPU sur la même puce, d'abord en séparé, puis au final avec partage de registres et d'unités fonctionnelles.

Suivre le flux des commentaires

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