du chauffage pour chez aileF

#1

Bon théoriquement ça n’a pas un grand intérêt de faire tourner des modèles sur des ordis isolés. Mais en considérant le fait que la puissance des ordis individuels ne cesse de croître, et qu’ici on a des grosses machines, ça vaut le coup de tenter.

[quote]ce sont des Xeon E5-1650 à 3.2Ghz sur 12 coeurs
32 ou 64 Go de ram

je peux en avoir une bonne dizaine la nuit. Si je motive plus de users, ça peut monter à 30-40.
à une époque on était pas loin de 150 à faire du SETI@home dans le studio.
[/quote]
Donc voila déjà un premier benchmark pour voir ce qu’elles ont dans le ventre.
J’ai durement bataillé pour réussir à faire tourner ce vilain modèle sous windows.

Donc pour tester il faut :

  • Windows 7 (ou 8?) 64bits.
  • Plein de RAM. Mon ordi de 4Giga en avait pas assez, donc je suppose qu’il en faut plus.
  • Quelques dizaines de Go d’espace libre sur le disque dur.

Ce bench est fait pour tester les machines de aileF. Il n’a pas un grand sens sur d’autres ordis.

  • télécharger et décompresser tous les fichiers
    http://meteo-parapente.com/test-wrf.zip

  • fermer tous les programmes ouverts pour ne pas gaspiller de puissance

  • en double cliquant sur le fichier bench.bat, on lancer la procédure. Normalement ça dure longtemps (1 heure, voir plus ?), et les ventilos de l’ordi vont se mettre à tourner vite.

Théoriquement ça marche direct, et ça ressemble à ça :

Il se peut que le pare-feu interfère.

Et ensuite une fois que l’ordi a bien chauffé pendant longtemps, ça va afficher un message genre « fini, appuyez sur une touche pour continuer ».

Il ne te restera plus qu’à lancer le test-matos.bat pour lister la config de ta machine.

Ensuite tu fais un fichier zip avec tous les fichiers texte que ça aura généré :
matos.txt, results.txt, rsl_xxxx.txt … Et tu m’envoies tout ça pour que j’analyse

Après ça, on pourra tester avec des vrais prévis.

#2

je regarde ça demain midi,

d’abord avec les machine de prod (les gros xeons avec 23/64go de ram) mais qu’on ne branchera pas en netfinity avant 3 ans.

mais aussi, j’ai l’autorisation de faire des tests avec la génération d’avant, des T3400 de dell, moins pruissants, mais je devrais pouvoir ajouter des cartes netfinity dedans. et booster la ram à 16 ou 32Go
de mémoire, ce sont des Core2 quad cpu Q9450 à 2.67Go (la même que la mienne à la maison mais avec plus de ram)

je te dis ça demain.

pour ce qui est des pare-feu, il s’agit de celui de la boite (sur lequel je ne peux rien faire), je passerais probablement la machine sur la connexion adsl si besoin (moins perfo, mais grande ouverte).

#3

yes hésites pas à m’appeler si besoin.

Le pare-feu de la boite ne devrait pas poser problème.
C’est si il y en a un installé sur les ordis que ça risque de gêner.

#4

alors ?

#5

alors je suis resté en reu toute la journée, et j’ai du partir tot.
je fais ça demain. sorry.

#6

c’est en cours

#7

ça se stabilise vers les 6Go de ram et 50% des coeurs :

#8

fini :

#9

Donc là dessus la meilleure config c’est 12 process de 1 thread chacun.

371.252 s
371.813 s
372.243 s

On frôle les 6 minutes 12. C’est pas mal.

A titre de comparaison :

  • 12 min sur un i7 2600, dual channel DDR3-1333MHz
  • 6m32 sur un i7 3820, quad channel DDR3-2133MHz
  • ~ 2min sur 3x core i7 3820 connectés en infiniband
  • 29min sur une instance Amazon EC2 c1-XL (c’est beau le cloud !)
  • 90 min sur un Dell Inspiron 1545
#10

Bon maintenant on peut faire une tentative avec 2 pc connectés par le réseau.

Extraire le fichier zip sur les deux pc, au même endroit exactement.
Le mieux c’est de faire dans c:\test-wrf

(J’ai jamais essayé ça sous Windows / avec ces outils. Ça va probablement rater.)

Sur les deux pc :

  • ouvrir l’invité de commande. Menu démarrer et taper « cmd » + entrée

  • dans l’invité, taper « ipconfig » et noter les adresses ip des deux pc

  • taper « cd c:/test-wrf/wrf » pour se mettre au bon endroit

  • et lancer le gestionnaire MPI : « smpd.exe -d ». Laisser la fenetre ouverte jusqu’à la fin du test.

Sur un seul des deux pc :

  • ouvrir un deuxième invité et « cd c:/test-wrf/wrf »

  • lancer le process
    « ptime mpiexec -n 24 -hosts 2 ipA 12 ipB 12 c:/test-wrf/wrf/wrf.exe »

remplacer ipA et ipB par les adresses ip des deux machines.

Si tout se passe bien, tu auras à la fin des 3 minutes un message du genre WRF SUCCESS COMPLETE, suivi de combien de temps ça a mis.

Le mieux c’est de le faire tourner quelques fois pour voir.

Si ça rate, envoie moi une capture d’écran.
Et si ça marche correctement, on pourra ensuite tester avec plus d’ordis.

#11

pas de version Mac / Linux ? :wink:

Il commence à faire froid par ici …
:canape:

#12

[quote]pas de version Mac / Linux ?
[/quote]
Malheureux, si tu savais la galère que ça a été de réussir à compiler ce truc pour windows.

Il a fallu reprendre les vielles habitudes…

https://pbs.twimg.com/media/Bexi-9iCYAAcIBK.png:large

#13

je dois filer du taff, ya piwaille qui mange à la maison ce soir. je tenterais de faire ça depuis la maison via le vpn.

hé oui, je fricote avec le taulier… on fait ce qu’on peut pour avoir plus de place dans sa boite à mp :stuck_out_tongue:

#14

ben c’est pas trop grave, ce qui est grave, c’est de l’avouer en public :sors:

#15

c’est parceque je me prépare à sous-louer mes service :bu:

#16

@Nicolas : je t’ai envoyé un mp avec le résultat des tests.

#17

La question quand on aborde la parallélisation n’est pas forcément de faire tourner le modèle en entier sur des ordis isolés, mais de découper le calcul en tranches et de faire tourner chaque partie du calcul sur pleins de machines.
le code se prête-t-il à de la parallélisation ?

J’ai un temps dans ma jeunesse pas si lointaine parallélisé un code de monte carlo écrit en fortran 77 (http://fr.wikipedia.org/wiki/Méthode_de_Monte-Carlo). Au lieu de tourner en 2h environs sur un Cray II, il tournait en 1 semaine sur une quinzaine de stations Sun Solaris et SGI. Quel avantage dans ce contexte si c’était plus lent ? L’accès au créneau de temps de calcul sur le Cray II était d’un mois. En 1 mois les chercheurs ne pouvaient lancer qu’une simulation. Alors qu’avec le code parallélisé, ils pouvaient faire 4 simulations par mois en utilisant leurs stations de travail sous exploitées. Et en utilisant massivement la centaine de stations du site ils auraient pu en faire plus encore, mais je n’ai pas vu cette phase de déploiement, j’ai fini mon service militaire entre temps.

La limite dans la parallélisation est quand le temps de calcul pour agréger les calculs distribués devient plus grand que le temps de calcul des parties calculées.
On détermine ainsi le meilleur rapport entre la taille du calcul distribué (dépend de la puissance des noeuds), le temps réseau pour rapatrier les données (dépend du volume) et le temps d’agrégation.

Je ne sais pas si la parallélisation pourrait être une piste sachant qu’aujourd’hui il y a des solutions existantes pour faire tourner du calcul distribué et des agents et des API comme sur l’autre post dans lequel BOINC était évoqué.

http://boinc.berkeley.edu/
http://boinc.berkeley.edu/trac/wiki/ProjectMain
http://boinc.berkeley.edu/trac/wiki/AppIntro

Bon courage dans vos tests en tout cas !

#18

[quote]La question quand on aborde la parallélisation n’est pas forcément de faire tourner le modèle en entier sur des ordis isolés, mais de découper le calcul en tranches et de faire tourner chaque partie du calcul sur pleins de machines.

le code se prête-t-il à de la parallélisation ?
[/quote]
Ce code est conçu dès l’origine pour être parallèle. C’est un truc fait pour tourner sur des milliers de CPU.

Le truc c’est qu’en météo, on peut pas vraiment découper le boulot en petite tranches indépendantes. Pour calculer la météo d’ici il faut voir ce qui se passe chez le voisin.

Donc sur les infras de calcul météo classiques (y compris la mienne) on utilise des « super réseaux » (ex: Infiniband) pour partager la RAM de tous les ordis. Ainsi le modèle peut ajuster son calcul en prenant en compte les résultats des ordis voisins.

Ça n’est pas possible de faire ça sans un matériel spécifique, et encore moins au travers d’internet.

Il faut donc ici faire tourner pleins de petits modèles au lieu d’un seul gros. Ce qui induit des prévis de moins bonne qualité, car plus le modèle tourne sur une petite zone, plus le domaine est contaminé par des effets de bord, et moins il prends en compte ce qui se passe à coté.

Jusqu’à peu, cela n’avait pas un réel intérêt : les ordis individuels ne pouvaient pas calculer une zone suffisamment grande.

Aujourd’hui la situation est différente car la puissance de calcul a considérablement augmentée, et la ram ne coûte plus rien.

Sur des ordis « grand publics », comme des portables, c’est encore limite. Par contre sur les dernières générations de serveurs, workstation ou de pc gamers (sockets LGA2011 / 4 canaux mémoire) ça commence à envoyer suffisamment de purée.

Et comme là on m’en propose gentillement une petite quarantaine…

#19

tu me dirais quand tu auras eu le temps de regarder mes retours Nicolas.
Pour le moment j’ai vérifié, les machines que l’on pourrait mettre en infinyband, ce sont des dual channel seulement. (T3400 DELL)

#20

Oui j’ai vu, ça a raté. Je pense que c’est le pare-feu de la boite qui bloque.
C’est pas dramatique. Celui là c’était surtout par curiosité.

Bon basé sur les pas trop mauvais résultats au test, on doit pouvoir faire un sacré truc.

Calcul très approximatif : avec une cinquantaine de ces machines, je peux faire des prévis 12km à 7 jours pour le monde entier !

Donc je propose la chose suivante :

  • on met à profit cette puissance pour déjà faire des prévis « open » là où ça aura un intérêt immédiat : Afrique, Amérique du Sud… Ça démontre l’utilité de la démarche et nous donne déjà une première masse critique.

  • avec ce premier démonstrateur, je lance le programme « OpenMeteo@home : calculez la météo chez vous pour améliorer l’agriculture, les économies d’énergie et la prévention des catastrophes ». Relayé dans les médias avec l’appui d’Etalab, de l’Open Knowledge Foundation et de quelques autres. Faut juste faire un truc suffisament sexy, avec des programmes pour windows / mac / linux pour contribuer en quelques clics. Éventuellement via BOINC pour donner encore plus de visibilité.

  • ça nous permets de racoler tout pleins de nouveaux gens, qui viendrons prendre le relais calculer la météo de là bas avec leurs ordis, libérant de plus en plus de puissance de calcul pour améliorer nos prévis vol libre.

Tu en penses quoi ?