Version imprimable
J'ai une question, je fais pas mal de calcul numerique pour ma these de physique et j'aimerais avoir un eclaircissement sur le MPI et les threads. Je fais uniquement du séquentiel donc je ne suis pas concerner par les multicore, mais j'aimerais comprendre c'est quoi la différence entre les threads (de pthread en c) et MPI?
l'un utilise vraiment explicitement les multiproc et l'autre juste des multi tache sur mono ou multi proc? ou je me gourre complet?
Les deux peuvent utiliser le multi-processeur, mais la différence est dans la séparation des données.
- En multi-thread, il n'y a qu'un seul processus (mais chaque thread peut tourner sur son propre processeur, si c'est le kernel qui s'en occupe comme sous Win32), toutes les données sont partagées (même si chaque thread a sa propre pile, un pointeur sur la pile d'un autre thread reste valide).
- MPI, c'est du multi-processus, donc mémoires séparées, et les échanges se font par "messages".
Bizarrement le C99 était prévu pour minimiser les différences entre le C et le C++ et finalement, c'est le C++ qui va évoluer pour s'adapter :cfou:Citation:
Envoyé par Jean-Marc.Bourguet
Y a déjà eu une extension qui a été approuvée : Bounds-checking interfaces (n1147), mais ça serait un bon début que le C99 soit implémenté par les compilateurs les plus utilisés !Citation:
Envoyé par Jean-Marc.Bourguet
Ca n'a certainement pas ete un critere dans l'adoption de chose comme inline et complex (deux cas ou C99 introduit quelque chose de disponible en C++ de maniere incompatible).Citation:
Envoyé par gege2061
C'est un TR. Rien ne dit que ce sera integre dans une prochaine version de la norme. (Toute la lib de TR1 en C++ par exemple ne se retrouvera pas dans C++0X).Citation:
MPI est une approche possible sur certains programmes mais manque de generalite.Citation:
Envoyé par souviron34
Je ne vois aucun rapport entre threads et COMMON.Citation:
C'est d'ailleurs la même chose pour les threads... A moins qu'il y ai eu une évolution des OS que je n'ai pas suivi, la fonctionalité recouverte est exactement identique aux COMMON en Fortran, disponibles également en Pascal, il me semble également (mais mes explorations dans ce domaine remontent à loin) en C, et en assembleur via les PSECT, associée aux sémaphores globaux. Car, détrompez-moi si je dis une bêtise, mais TOUS les OS réservent une partie PHYSIQUE du disque pour des données communes.
Pour MPI, ça a été fabriqué POUR le parallèlisme, donc je ne vois pas l'intérêt de développer des extensions à des langages non faits pour. Qu'on modifie MPI si il ne répond pas à toutes les attentes, cela a plus de sens...Citation:
Envoyé par Jean-Marc.Bourguet
En ce qui concerne le pbe threads/common, il me semble avoir compris (je ne sais pas, juste d'après ce que j'ai lu sur le forum, puisque jamis utilisé les threads) que l'argument était le partage des données. Ce que fait exactement le common, y compris avec la synchronisation...
Il y a aussi le fait qu'avoir un seul processus multi-thread est plus léger qu'avoir N processus mono-thread.
D'abord à la création, mais aussi à l'exécution : Les commutations de contexte sont moins couteuses d'un thread à l'autre que d'un processus à l'autre.
De plus, aucune sérialisation n'est nécessaire pour communiquer des données d'un thread à l'autre: Tous les pointeurs valides dans un thread sont valides dans tous les autres...
MPI a ete concu pour parallelliser un certain type d'application (en simplifiant, du calcul sur des matrices avec chaque noeud qui fait ce qu'il faut sur sa partie de matrice). Si tes appli rentrent dans cette classe, c'est bien. Sinon, ce n'est meme pas un debut d'architecture repartie.Citation:
Envoyé par souviron34
Ou Fortran a fortement change (ce qui est le cas, mais j'aimerais confirmation que les changements portent aussi sur ca, ce qui m'etonne), ou COMMON ce n'est que des variables globales sans meme une verification du type.Citation:
En ce qui concerne le pbe threads/common, il me semble avoir compris (je ne sais pas, juste d'après ce que j'ai lu sur le forum, puisque jamis utilisé les threads) que l'argument était le partage des données. Ce que fait exactement le common, y compris avec la synchronisation...
Je m'en suis servi sur des problèmes n'ayant rien à voir avec ça...Citation:
Envoyé par Jean-Marc.Bourguet
Pour plus d'info http://www-unix.mcs.anl.gov/mpi/
Extraits des buts :
Citation:
The goal of the Message Passing Interface, simply stated, is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, efficient, and flexible standard for message passing.
Citation:
The main advantages of establishing a message-passing standard are portability and ease-of-use. In a distributed memory communication environment in which the higher level routines and/or abstractions are build upon lower level message passing routines the benefits of standardization are particularly apparent. Furthermore, the definition of a message passing standard, such as that proposed here, provides vendors with a clearly defined base set of routines that they can implement efficiently, or in some cases provide hardware support for, thereby enhancing scalability.
The goal of the Message Passing Interface simply stated is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, efficient, and flexible standard for message passing.
A complete list of goals follows.
- Design an application programming interface (not necessarily for compilers or a system implementation library).
- Allow efficient communication: Avoid memory-to-memory copying and allow overlap of computation and communication and offload to communication co-processor, where available.
- Allow for implementations that can be used in a heterogeneous environment.
- Allow convenient C and Fortran 77 bindings for the interface.
- Assume a reliable communication interface: the user need not cope with communication failures. Such failures are dealt with by the underlying communication subsystem.
- Define an interface that is not too different from current practice, such as PVM, NX, Express, p4, etc., and provides extensions that allow greater flexibility.
- Define an interface that can be implemented on many vendor's platforms, with no significant changes in the underlying communication and system software.
- Semantics of the interface should be language independent.
- The interface should be designed to allow for thread-safety.
Absolument pas.... Je crois que tes souvenirs sont flous..Citation:
Envoyé par Jean-Marc.Bourguet
D'une part, en ce qui concerne la vérification des types, si on se place en Fortran, les COMMON ne sont accessibles que via les BLOCK DATA, qui définissent les variables, leurs types, leur ordre, leurs dimensions, etc.. depuis les premières définitions de Fortran
D'autre part, le mécanisme par lequel ces COMMON marchent sont par l'écriture PHYSIQUE sur le/les secteurs disques définis par l'OS comme étant commun(s) à tous. Je le répète, ce qui est accessible via l'nstruction PSECT en assembleur. Et par conséquent, même si cela n'est pas documenté très fortement, accesible à tous les langages (voir la rubrique de Barnard Cassagne pour le C http://c.developpez.com/cours/bernar...00000000000000 ou en assembleur VMS par exemple http://h21007.www2.hp.com/dspp/files...rm/lrm0598.htm ou l'équivalent sous Windows http://msdn2.microsoft.com/fr-fr/lib...x6(VS.80).aspx).
<hs>
Euh, en Fortran, un common block, c'est le moyen d'avoir des variables globales. Cela definit un segment de memoire nomme qui est accessible par toutes les routines du programme qui importent ce bloc. Rien d'autre. Depuis Fortran 90, il est deconseille d'utiliser des common. Ils sont remplaces par les modules.Citation:
Envoyé par souviron34
</hs>
Je suis d'accord avec toi, c'est devenu fortement déconseillé. Cependant, il y a 2 usages du COMMON :
1) déclarer des variables communes dans UN programme :
ce que tu cites (avec d'ailleurs applications entre C et Fortran : http://www.nersc.gov/vendor_docs/int...1/pgwuscom.htm
2) partager des données communes parmi PLUSIEURS programmes.
Cela fait trop longtemps que j'ai pratiqué pour me souvenir, mais je suis quasi-sûr que lorsqu'on définit des "BLOCK DATA", ceux-ci sont PHYSIQUEMENT stockés sur le disque (et accessibles par d'autre langages et/ou programmes).
Je me souviens l'avoir fait en assembleur sur un PDP.
Mais enfin, le fond du problème n'était pas là. C'était de dire qu'il est CERTAIN que n'importe quel OS réserve une place PHYSIQUE sur le disque pour ses opérations et data. Et qu'il y a forcément moyen d'y accéder.
<hs>
Faire de l'IPC en utilisant des COMMON BLOCK est effectivement possible, mais c'est acrobatique. Avec gfortran, on peut forcer l'adresse a laquelle le bloc va se trouver. Sous HP-UX, on a la directive SHARED_COMMON. Bref, c'est super pas portable...Citation:
Envoyé par souviron34
</hs>
La gestion de la memoire a tellement evoluee depuis la Grande Epoque que rien n'est certain. Les OS modernes utilisent des MMU, donc cela me semble difficile.Citation:
C'était de dire qu'il est CERTAIN que n'importe quel OS réserve une place PHYSIQUE sur le disque pour ses opérations et data. Et qu'il y a forcément moyen d'y accéder.
:D :D sans parler de grande époque....Citation:
Envoyé par DaZumba
que ce soit sur les systèmes *n*x (dans /tmp au minimum, dans /var, et dans d'autres fichiers (comme /etc ) des données sont physiquement partagées (exemple avec /etc/services)..