Non, a priori ça tourne sous SUPER-UX (http://en.wikipedia.org/wiki/SUPER-UX ). Je ne sais d'ailleurs pas si linux tourne sur des machines vectorielles et si GCC sait bien gérer ce genre de machines aussi.
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.
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...
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...
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.
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
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.
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...
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"
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.
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
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.
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)
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
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.
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.
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).
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
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.
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.
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é :)
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.
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.
# Un truc super moderne...
Posté par Dr BG . Évalué à 10.
Enfin, je dis ça, je ne sais pas.
[^] # Re: Un truc super moderne...
Posté par kadreg . Évalué à 8.
D'ailleurs, ça se confirme :
http://www.lemondeinformatique.fr/actualites/lire-meteo-fran(...)
[^] # Re: Un truc super moderne...
Posté par earxtacy . Évalué à 3.
[^] # Re: Un truc super moderne...
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Un truc super moderne...
Posté par med . Évalué à 8.
# Comment font-ils ?
Posté par Matthieu . Évalué à 3.
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 Ju Hash (site web personnel) . Évalué à 10.
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 abgech . Évalué à 4.
s/carrés/cubes/
[^] # Re: Comment font-ils ?
Posté par chl (site web personnel) . Évalué à -1.
[^] # Re: Comment font-ils ?
Posté par soulflyb (Mastodon) . Évalué à 9.
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 Hrundi V. Bakshi . Évalué à 2.
http://www.lefigaro.fr/marches/20070510.WWW000000435_risque_(...)
[^] # Re: Comment font-ils ?
Posté par lasher . Évalué à 4.
[^] # Re: Comment font-ils ?
Posté par Thomas Douillard . Évalué à 7.
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 Mais qui suis-je ? :) . Évalué à 3.
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 bartman . Évalué à 1.
[^] # Re: Comment font-ils ?
Posté par Nicolas Schoonbroodt . Évalué à 3.
[^] # Re: Comment font-ils ?
Posté par bartman . Évalué à 1.
Poincarré
[^] # Re: Comment font-ils ?
Posté par Ontologia (site web personnel) . Évalué à 2.
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 Troy McClure (site web personnel) . Évalué à 1.
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 beagf (site web personnel) . Évalué à 4.
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 Nicolas Boulay (site web personnel) . Évalué à 5.
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 patrick_g (site web personnel) . Évalué à 2.
Certes en 2009 il devrait être plus puissant mais bon...
[^] # Re: concours de b*te
Posté par Troy McClure (site web personnel) . Évalué à 1.
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 lasher . Évalué à 3.
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 Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: concours de b*te
Posté par lasher . Évalué à 2.
[^] # Re: concours de b*te
Posté par Troy McClure (site web personnel) . Évalué à 2.
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 lasher . Évalué à 3.
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 Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: concours de b*te
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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 Ontologia (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Pourquoi ne pas utiliser de processeurs graphiques ?
Posté par lasher . Évalué à 2.
[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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.