Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 18 sur 18
  1. #1
    Bonjour à tous :

    Bon, ces derniers temps je suis amené à travailler sur Super-calculateur.
    Et notamment a programmer dessus, ce qui est assez ardue, il y a toute les histoire de parallélisation ect...

    Je me suis un peu renseigné sur les différente méthode de programmation parallèle, et il s'avère que l'efficacité de ces méthodes dépend avant tout de l'architecture du Calculateur.

    Voici les caractéristique du calculateur :

    HP RX 8640
    8 processeurs Itanium2 Montecito bi-core 1,6Ghz/24MB
    64 Goctets RAM
    1 baie de stockage RAID 5 fiber channel partagée avec ETA (Opteron) capacité actuelle : 800 G-octets, disques 15000 t/mn
    1 baie de stockage RAID 5 en attachement direct RAID 5 , capacité 800 Go, disques 15000 t/mn
    Logiciels :
    Système d’exploitation RedHat AS 4 (+ GFS pour espace disque partagé)



    Bref, je n'ai trouvé sur le net, que très peu d'info en français sur ce modèle, et les rares infos en anglais sont malheureusement remplient de jargon technique que j'ai du mal à comprendre.

    Voila, ce que je cherche avant tout à déterminer c'est si le calculateur est à mémoire partagé ou distribué... Ce qui change complètement mon mode de programmation, et sans cette info, je ne peut pas faire grand chose.

    Voila voila.
    Dernière modification par Nilsou ; 22/04/2010 à 11h28.

  2. #2
    Montecito = memoire partagée il me semble
    Mes propos n'engagent personne, même pas moi.

  3. #3
    Ok, déjà ça ça m'aide.

    Si vous avez d'autres info sur ce modèle, je suis preneur.

    Selon ces articles :
    http://www.irit.fr/Toulouse2009/Toul...rs/paper20.pdf
    https://rqchp.ca/modules/cms/checkFi..._parallele.pdf

    Je devrais donc utiliser une programmation en OpenMP, alors que tout les programmes du labo sont programmé en MPI...

    ça remet en question beaucoup de chose... alors si quelqu'un peut me confirmer l'affirmation de neo_13, je serais rassuré.

  4. #4
    Les montecito n'ont pas de controleur mémoire intégré, alors je vois mal comment ils gèreraient autrement.
    Mes propos n'engagent personne, même pas moi.

  5. #5
    Ok, on vient de me poster une réponse par MP , la voici :

    Citation Envoyé par bidou.bidou
    Bonjour, Comme je n'arrive pas à poster sur le forum, message privé. Effectivement les Itaniums sont le plus souvent des architectures à mémoire partagée. Néanmoins, ça n'empêche absolument pas de développer et de faire tourner des applications MPI dessus. Le passage de message se fera juste en utilisant un morceau de mémoire partagée plutôt que le réseau. Niveau efficacité, je reste persuadé que sauf cas particulier ou code particulièrement bien écrit, les implémentations MPI sont toujours plus rapide. Le principal intérêt d'openmp, c'est qu'il permet de paralléliser des codes séquentiels avec un effort bien moindre. Si vous avez déjà des codes MPI, restez dessus.
    Voila, comme ça vous pouvez réagir dessus. Si quelqu'un à déjà écrit des code parallèle dans ces deux langage (bibliothèque plutôt), je suis tout ouïe quant à ses avis.

  6. #6
    http://forum.canardpc.com/showpost.p...15&postcount=1

    Pour ceux qui veulent prendre part à la discussion.
    Mes propos n'engagent personne, même pas moi.

  7. #7
    Bref, bidou bidou me propose comme solution de faire tout simplement deux code , l'un en open MP et l'un en MPI.

    Dites moi : y a t'il une différence entre 16 processeur et 8 processeur bi core.

    Un truc qui influerais sur la programmation?
    Je suppose que faire travailler les core deux par deux pourrait être plus performant non?

  8. #8
    Citation Envoyé par Nilsou Voir le message
    Bref, bidou bidou me propose comme solution de faire tout simplement deux code , l'un en open MP et l'un en MPI.
    Euh, et pourquoi pas rester entièrement en MPI?
    Le papier du LRI que tu cite donne plutôt raison au premier post de bidou bidou : il y a peu de différence entre les perfs d'OpenMP et MPI sur une machine à mémoire partagée.
    Il faut juste avoir une implémentation de MPI qui connaisse la topologie de la machine et ne fasse pas n'importe quoi...

    Si le code que tu as est aussi crade que je pense, les quelques % que tu pourrais gratter en passant en OpenMP sont bien le moindre de tes soucis...

    Dites moi : y a t'il une différence entre 16 processeur et 8 processeur bi core.

    Un truc qui influerais sur la programmation?
    Je suppose que faire travailler les core deux par deux pourrait être plus performant non?
    Oui, il faut que tu règle l'affinité de tes processus MPI pour les épingler chacun sur un core et qu'il ne bougent plus...

    Pour rester dans les trucs franco-français, tu as hwloc pour analyser la topologie de la machine :
    http://www.open-mpi.org/projects/hwloc/

  9. #9
    Tiens un papier de Franck et Daniel . Je vois que les sujets n'ont guere varie .

    De maniere generale tu peux beneficier de latences et bande passante de communication reduite entre deux processeurs sur le meme socket vu qu'ils partagent leur cache si tu ecris bien ton application en memoire partagee. En pratique si ton application est si sensible aux latences de communication entre deux processeurs, elle est mal ecrite et les performances seront mauvaises: et c'est la raison fondamentale pour laquelle que tu passes par MPI ou OpenMP, une application bien parallelisee sera relativement peu sensible aux communications inter-processeurs, vu que l'essentiel de ton travail d'optimisation sera de reduire ta dependance a celles-ci.

    C'est un peu comme les questions: mon programme C sera-t'il plus rapide que mon programme C++ ? Tu dependras bien plus de la qualite du programme que du langage lui meme.

    Apres si ton programme est parrallelisable en 2 niveaux, des paires de threads qui communiquent plus souvent entre eux et sont plus sensibles a la latence et que tu force leur affinite pour etre groupes sur la machine, tu peux avoir des benefices, surtout si tes paires de threads echangent de grosses quantite de donnees, rester en memoire partagee t'economiserait des copies.

    Au final, tu ne peux prendre des decision d'optimization qu'apres avoir analyse et profile ton application, et connaitre le type d'echange de donnees inter-processeur et ta dependance aux communications. Il y a certains cas extremes ou OpenMP pourrait presenter des avantages importants, mais ce n'est pas le cas de maniere generale.

    PS: je n'ai dit que des banalites, mais vu que tu n'as pas parle du type d'application sur laquelle tu bosses c'est difficile d'etre plus specifique.
    fefe - Dillon Y'Bon

  10. #10
    Je bosse sur une simulation de propagation d'onde dans un milieu.

    On peu le paralléliser de plusieurs manière, mais tout en conservant beaucoup de variables commune.

    l'onde se propage et on calcule à chaque pas de temps, l'état de tout les pixel.

    Comme ces états ne dépendent que des état précédente, je vois la chose comme ça :

    a chaque pas de temps, je parallélise le calculs de chaque pixel, ensuite je récupère toute les variable dans un coin commun, et ensuite les proc récupère ces variables et recommence le calcul;

    Ect...

  11. #11
    Citation Envoyé par Nilsou Voir le message
    Je bosse sur une simulation de propagation d'onde dans un milieu.

    On peu le paralléliser de plusieurs manière, mais tout en conservant beaucoup de variables commune.

    l'onde se propage et on calcule à chaque pas de temps, l'état de tout les pixel.

    Comme ces états ne dépendent que des état précédente, je vois la chose comme ça :

    a chaque pas de temps, je parallélise le calculs de chaque pixel, ensuite je récupère toute les variable dans un coin commun, et ensuite les proc récupère ces variables et recommence le calcul;
    Ca ne me parait pas clair : tu veux dire que chaque pixel est calcule independemment ou bien que les calculs appliques a chaque pixel sont parallelises ?

  12. #12
    Je pense qu'il veut traiter independament chaque pixel (ou groupe de pixel, il vaut mieux partitionner le probleme en autant de part que tu as de CPUs) et mettre une barriere entre chaque "cycle" de simulation.

    C'est une parallelisation plutot adaptee a un systeme a memoire partagee, vu que tu parts du principe que tout le monde va acceder toutes les donnees en lecture en parallele. Bien entendu, rien ne t'empeche de passer un message a tout le monde avec le pixel que tu viens de produire, mais tu vas le copier n=16 fois.

    Je doute que tu beneficies vraiment du fait que chacun de tes noeuds soit un double processeur avec une telle parallelisation. Les communications des 2 cpus sur le meme noeud iront plus vite, mais au final tout le monde attendra la barriere pour passer a l'etape suivante.

    Est ce que tu as besoin de tous tes pixels pour demarrer l'etape suivant ? Si ce n'est pas le cas, essayer de resoudre ceux dont tu as besoin et qui sont deja produit aiderait grandement (ca eviterait une barriere ou tout le monde attend que les resultats deviennent visible en memoire et permettrait de revouvrir les communications avec des calculs).

    De maniere generale dans une machine a memoire partagee comme ta HP tu vas payer dans les 200 a 300 cycles pour echanger des donnees partagees (donc autant les grouper par paquets pour que ta penalite de latence soit absorbee en transferant plus de donnees). Tu payeras le meme type de latence *2 pour passer un message, donc il faut que ton calcul par CPU entre 2 communications prenne quelques milliers de cycles pour que ton appli scale (sauf si tu trouves un moyen de recouvrir tes communications avec des calculs).
    fefe - Dillon Y'Bon

  13. #13
    J'ai en effet besoin de tout les pixels à l'étape suivantes.

    Donc, ouais il vont attendre, mais ce sera déjà plus rapide qu'avec un seul cpu .

    Donc de toute manière les données seront passé par paquet a la fin de chaque cycle.

    Un schéma plutôt simple en fait.

  14. #14
    Note que tu peux peut être le faire par partie, façon "arbre", de sorte que ça masque certaines latences...
    Mes propos n'engagent personne, même pas moi.

  15. #15
    Citation Envoyé par Nilsou Voir le message
    J'ai en effet besoin de tout les pixels à l'étape suivantes.

    Donc, ouais il vont attendre, mais ce sera déjà plus rapide qu'avec un seul cpu .

    Donc de toute manière les données seront passé par paquet a la fin de chaque cycle.

    Un schéma plutôt simple en fait.
    Oui mais tu n'es pas oblige de tous les consommer des le debut de la phase suivante, c'est ce que j'essayais de dire. Avec une parallelisation "simple" comme ca, si ton probleme n'est pas suffisament gros (pas assez de pixels) la parallelisationrisque d'etre nettement plus lente que l'appli non threadee.

    Cis dessous, par exemple (P1 calcul sur le groupe de pixel P1, "|" = synchro) tu as tous les pixels consommes dans la production de tous les pixels par phase.
    Code:
    -------------------------------------->temps
    CPU1 P1->P2->P3->P4=>P1 |___ P1->P2->P3->P4=>P1
    CPU2 P1->P2->P3->P4=>P2 _|__ P1->P2->P3->P4=>P2
    CPU3 P1->P2->P3->P4=>P3 __|_ P1->P2->P3->P4=>P3
    CPU4 P1->P2->P3->P4=>P4 ___| P1->P2->P3->P4=>P4
    mais ca sera probablement mieux parallelise en n'utilisant pas une barriere de synchronisation, mais une forme de pipeline qui permettra de reduire le temps des synchronisations.
    Code:
    -------------------------------------->temps
    CPU1 P1->P2->P3->P4=>P1 | P1->P2->P3->P4=>P1
    CPU2 ___ P1->P2->P3->P4=>P2 | P1->P2->P3->P4=>P2
    CPU3 _______ P1->P2->P3->P4=>P3 | P1->P2->P3->P4=>P3
    CPU4 ___________ P1->P2->P3->P4=>P4 | P1->P2->P3->P4=>P4
    Bien entendu au demarrage et a l'arret tu perdras les temps d'amorcage de pipeline, mais en regime continu c'est beaucoup plus rapide, surtout si tes communications sont couteuses face a tes calculs (si elles ne le sont pas c'est effectivement un probleme simple et pas besoin de trop s'embeter ).

    Tu remarqueras que cette 2 eme methode de parallelisation se prete assez bien au passage de message (probablement mieux que la premiere dans le cas de ce probleme).

    Tu nous dira quelle amelioration de perf tu recuperes avec ta premiere implementation parallele (ma premiere c'etait ~-10% de perf a chaque fois que j'ajoutais un core, mais le passage de message etait autrement plus lent que sur ton itanium... ).
    fefe - Dillon Y'Bon

  16. #16
    Oui, je vais voir tout ça, je vais essayer de programmer tout ça, ça risque d'etre un peu long, et il faut que je trouve le temps de le faire.

    En tout cas, merci beaucoup pour vos réponse, ça va bien m'aider.

  17. #17
    La classe générale de ton problème est celle des calculs de stencil, où l'état d'une cellule au temps t+1 dépend de l'état de ses voisins au temps t.

    La première page de résultats en cherchant "stencil computation" dans Google Scholar donne un bon aperçu de l'état de l'art...

    L'idée de base est que tu peux faire se recouvrir partiellement les zones traitées par chaque processeur, ça fait plus de calcul mais moins de comm/synchros. Après, ça fait un paquet de paramètres qu'il faut optimiser en fonction de la machine, ce que font ces papiers de manière plus ou moins générique.

    (Je fais l'hypothèse que l'état de ton pixel dépend de celui de tous ses voisins, pas juste ceux dans une direction. Sinon c'est effectivement plus simple...)

    Avant de te lancer dans le code, cherche un peu s'il n'y a pas un truc déjà tout écrit où tu n'ait qu'a plugger les équations que tu veux

  18. #18
    Merci de la précision, je regarderais. (cela dépend effectivement des cellules voisine... )

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •