openmpvsmpi

OpenMP vs. MPI

Arenas Artiga, Glòria

Granell Ber, Joan

Estudiant de grau en Enginyeria Informàtica Universitat Rovira I Virgili Tarragona, Catalunya gloria.arenas@estudiants.urv.cat

Estudiant de grau en Enginyeria Informàtica Universitat Rovira I Virgili Tarragona, Catalunya joan.granell@estudiants.urv.cat

Abstract—Aquest document ens informarà sobre com treballen el OpenMP i MPI. Introduint-los una mica, explicant la seva història, comparant-los una mica i veien alguns exemples clarificadors.

Keywords—Flynn; MIMD; multiprocessadors; OpenMP; MPI;

multicompputadors;

1. INTRODUCCIÓ En la taxonomia de Flynn ens trobem amb quatre classificacions d’arquitectures paral·leles que son, SISD, MISD, SIMD i per últim MIMD. Que tracta de executar una/varies instruccions amb una/varies dades. En aquest document ens centrarem amb MIMD. La tècnica MIMD s’utilitza per proporcionar paral·lelisme, és a dir, molts càlculs executats simultàniament amb una programació multi-fil (multi-thread en anglès). Es divideixen en memòria compartida o distribuïda. Amb memòria compartida, trobem els multiprocessadors, i el programador utilitza variables globals de comunicació de tipus OpenMP. En canvi, els multicomputadors (que son un conjunt de multiprocessadors), tenen memòria privada i el programador utilitza canals de comunicació (enviar/rebre) de tipus MPI. Per tant, farem servir OpenMP i MPI per a que el processos siguin capaços de comunicar-se amb els altres processos mitjançant enviar i rebre missatges. Aquest tipus de tècnica se l’anomena interfície de pas de missatges.

El pas de missatges és un model de comunicació molt utilitzat en computació paral·lela. Actualment s’usa molt aquesta tècnica per desenvolupar aplicacions importants bastades en aquest paradigma. Aquestes aplicacions han demostrat que es possible implementar sistemes basats en aquest pas de missatges de manera eficient i portable. El creixement de volum i diversitat de les aplicacions van originar la necessitat d’aquest estàndard, i així es com van sorgir els estàndards dels quals parlarem.

2.

OPENMP

2.1 HISTÒRIA Un problema que tenien amb les directius de la memòria compartida, era que cada venedor feia la seva pròpia directiva.

Va ser als anys 90, quan els venedors de màquines de memòria compartida van proporcionar una base directiva similar a la

programació de Fotran. Les implementacions eren similars però divergents. El primer intent d’una norma va ser el projecte d’ANSI X3H5. No es va adoptar mai, ja que l’ús de la memòria compartida tampoc era gaire popular. De totes maneres, les noves arquitectures de memòria compartida, van començar a reprendre el seu interès. Va ser al 1997 quan l’estàndard OpenMP va sorgir. Liderats pel OpenMP Architecture Review Board (ARB). A partir d’aquí, OpenMP va anar evolucionant.

Inicialment, les especificacions de l’API van ser creats per separar per a C i Fortran. Des de 2005 es fan junts.

A l’actualitat, s’usa l’OpenMP 3.1.

2.2 QUÈ ÉS OPENMP? En les plataformes de multiprocessadors de memòria compartida, trobem que cada processador té la memòria principal compartida, es a dir, diferents processos comparteixen una àrea de memòria que utilitzen per compartir informació.

El problema que trobem, és quan tenim la mateixa dada en les memòries cau.

OpenMP permet el pas de missatges per a que els processadors es relacionin i diguin si han modificat una dada o no per poder treballar de manera paral·lela al resoldre un problema (un genera una dada que un altre utilitzarà). Amb OpenMP és el compilador el que paral·lelitza el codi i ha de ser assistit per directives que comentarem més endavant, donades pel programador. És capaç de generar codi per sistemes de memòria distribuïda, però és complicat e ineficient de implementar en sistemes de memòria distribuïda.

La comunicació es fa explícitament mitjançant pas de missatge que contenen informació. Permet un control fi de la comunicació, que és la part més costosa del càlcul en paral·lel.

Però això fa que la programació resulti més complexa.

OpenMP és una API (Interfície de Programació d’Aplicacions) que ens permet afegir concurrència a les aplicacions escrites en C, C++ i Fortran mitjançant paral·lelisme amb memòria compartida, aquest paral·lelisme el realitza amb el model fork-join que explicarem més endavant.

OpenMP té tres components complementaris: o

Conjunt de directives de compilador utilitzat pel programador per comunicar-se amb el compilador en paral·lelisme. #pragma omp <directiva> {<clàusula>}* <\n>

o

Una llibreria de funcions en temps d’execució. Aquesta habilita la col·locació i s’informa sobre els paràmetre paral·lels que s’usaran, com ara número de fils que hi haurà i el número de cada fil.

o

Número limitat de les variables d’entorn que poden ser utilitzades per definir en temps d’execució paràmetres del sistema en paral·lel, com el número de fils.

El desenvolupador de l’aplicació decideix com emprar aquests components. En el cas simple, només es necessitarien uns quant d’ells. Les implementacions varien amb el seu suport per tots els components de l’API. Els programes OpenMP aconsegueixen paral·lelisme exclusivament a través de fils: o

Un fil d’execució és la menor unitat de processament que pot ser programat per un sistema operatiu.

o

La idea d’una subrutina que pot ser programada de manera autònoma podria ajudar a explicar què és un fil.

o

Els fils existeixen dins dels recursos d’un únic procés.

Sense el procés, deixen d’existir.

o

Típicament, el nombre de fils equipara el nombre de processadors de la màquina. No obstant això, l’ús actual dels fils depèn de l’aplicació.

OpenMP és una manera de programar explícita, però no automàtica. Aquest ofereix al programador un control absolut de la paral·lelització. La paral·lelització pot ser tant simple com prendre un programa de sèrie i inserir les directives del compilador, o tant complexa com inserir subrutines per establir múltiples nivells de paral·lelisme.

2.3 MODEL D’EXECUCIÓ; TÈCNICA FORK-JOIN MODEL OpenMP utilitza la tècnica de Fok-Join Model per a una execució paral·lela. El model Fork-Join és un paradigma que prové dels sistemes Unix, on una tasca molt pesada, anomenada fil màster (master thread) es divideix en K fills (anomenats fork, forquilla) amb un menor pes, per desprès recol·lectar els seus resultats al final i unir-los amb un sol resultat, aquesta última operació s’anomena join.

Així doncs, l’execució amb el model Fork-Join, funciona de la següent manera; Quan s’inclou una directiva OpenMP, fa que estigui implicada una sincronització en tot el bloc. Es a dir, el bloc de codi es marcarà com a paral·lel i es llançaran fils segons les característiques que ens doni la directiva, i al final d’ella hi haurà una barrera per la sincronització dels diferents fils (si no s’indica el contrari amb la directiva nowait).

Explicat d’una manera més tècnica, tots els programes OpenMP comencen com un únic procés, l’anomenat fil màster.

El fil màster s’executa seqüencialment fins que es topa amb la primera regió paral·lela (parallel region en anglès). Llavors crea els k fills (forks). Les declaracions al programa que s’adjunta per la construcció de la regió paral·lela, són desprès executats en paral·lel entre els fils. Llavors, quan l’equip de fils acaben les declaracions a la construcció, sincronitzen i acabant fent una join (unió), deixant només un fil principal. El nombre de regions paral·leles i fils que els componen són arbitràries.

La següent imatge reflexa la idea principal de l’execució:

Una vegada en execució, els fils es comuniquen utilitzant variables compartides. L’ús inadequat de les variables compartides crea seccions crítiques. Per controlar-ho farem ús de la sincronització (semàfors) per protegir-se dels conflictes de dades. S’ha de tindre en compte, però que la sincronització és molt costosa, per tant, és sempre millor modificar com s’emmagatzemen les dades per minimitzar la necessitat de sincronització.

2.3.1

DIRECTIVES

Quan parlem de incloure directives OpenMP, parlem de incloure una sincronització obligatòria en tot el bloc. Es a dir, el bloc de codi es marcarà com a paral·lel i es llançaran fils segons les característiques que ens doni la directiva, i al final de la directiva hi haurà una barrera per la sincronització dels diferents fils, si no és que implícitament s’indiqui el contrari, es a dir, que s’indiqui que la directiva és nowait. Podriem dir, que totes aquestes directives són clàusules de sincronització. Aquí mostrarem uns dels exemples d’algunes directives d’OpenMP: ATOMIC. Especifica que hi ha una localització de memòria que ha de ser actualitzada atòmicament.

BARRIER. Sincronitza tot els fils d’un equip. Tots els fils es paren al la barrera (barrier) fins que tots els fils executen el barrier.

CRITICAL. Especifica que el codi només executa un fil al mateix temps.

FLUSH. Identifica un punt de sincronització al programa.

Es parla d’un punt de sincronització com un punt en l’execució del programa on la execució dels fils necessita fer una conscient vista de memòria. Això significa que una avaluació prèvia de expressions a les quals aquests objectes es refereixen seran completats i subseqüentment avaluats sense tindre de ser inicialitzats.

FOR. Causa la feina feta en un bucle dins d’una regió paral·lela per ser dividida pels fils.

MASTER. Especifica que només el màster del fil pot executar una secció del programa.

ORDERED. Especifica que el codi sota paral·lelització per bucle ha de ser executat com un bucle seqüencial.

PARALLEL. Defineix una regió paral·lela, que serà codi executat per múltiples fils en paral·lel.

SECTIONS. Identifica seccions del codi per ser dividides pels fils.

NO WAIT. Especifica que els fils que realitzen una feina específica poden ser executats sense la necessitat d’esperar-se per tots els altres fils de l’equip acabin. Amb l’absència

d’aquesta directiva, el fils trobarien la sincronització barrier al final.

SINGLE. Et deixa especificar que una secció del codi hauria de ser executada en un únic fil, no necessàriament en un fil màster.

THREADPRIVATE. Especifica a un fil que una variable és privada.

2.3.2

CLAUSES

Des de que OpenMP és un model de memòria compartida, moltes variables del codi per defecte són visibles per tots els fils. Però de vegades, les variables privades són necessàries per evitar seccions crítiques i allí es necessiten passar valors entre la part seqüencial i la part paral·lela de la regió (el codi del bloc executat en paral·lel), així doncs, les dades de gestió de l’entorn son introduïdes com data sharing attriubte clauses agregant-les a la directiva OpenMP. Les diferents tipus de clauses són: COPYING. Permet al fil accedir al valor del fil màster, per a una variable de threadprivate.

COPYPRIVATE. Especifica que una o més variables haurien de estar compartides per tots els fils.

DEFAULT. Especifica el comportament de les variables que no estan a l’abast en una regió paral·lela.

FIRSTPRIVATE. Especifica que cada fils hauria de tindre la seva pròpia instància de variable i que la variable hauria d’estar inicialitzada amb el valor de la variable, ja que existeix abans que la construcció paral·lela.

IF. Especifica si un bucle hauria d’estar executat de manera paral·lela o seqüencial.

LASTPRIVATE. Especifica que la versió del context de la variable es modifica cada equilibradament a la versió privada on qualsevol fil executa el final de la iteració o final de la secció.

NUM_THREADS. Modifica el número de fils en l’equip dels fils.

ORDERED. És requerit en un for paral·lel si la directiva ha de ser utilitzada en un bucle.

PRIVATE. Especifica que cada fil hauria de tindra la seva pròpia instància de variable.

REDUCTION. Especifica que una o més variables que son privades per cada fil són subjectes a una operació de reducció al final de la regió paral·lela.

SCHEDULE. Demana per la directiva for. Hi ha tres tipus de scheduling; 1.

Estàtica. Tots els fils són repartits per iteracions abans de ser executats els bucles.

2.

Dinàmic. Aquí algunes de les iteracions son repartides a un nombre més petits de fils. Quan un fil en particular acaba, retorna un altre de la iteració d’on ha sortit.

3.

Guiat. Un llarg tros de contínues iteracions assignades a cada fil dinàmicament. La mida del decrementa exponencialment amb cada successió a una mida mínima especificada al paràmetre (chunk).

son tros fins tros

SHARED. Especifica que una o més de les variables hauria de ser compartida per tots els fils.

3. MPI 3.1 HISTÒRIA MPI, Message Passing Interface, va començar a mitjans de 1991 quan un petit grup d’investigadors va començar a discutir-se. D’aquesta discussió van muntar un taller basat en els estàndards de pas de missatges. En aquest tallers discutien les funcions bàsiques essencials per un estàndard d’una interfície de pas de missatges. A finals del 1992, en una reunió del grup de treball del MPI es va decidir d’estandarditzar el procés. La majoria de venedors de computadores concurrents estaven involucrats amb MPI. Finalment, es va arribar a una proposta preliminar coneguda com MPI1, enfocada principalment en comunicacions punt a punt sense incloure rutines per comunicació col·lectiva i no presentava tasques segures.

L’estàndard final pel MPI va ser presentat a la conferència de Supercòmput al novembre del 1993, construint-se així el fòrum pel MPI. En un ambient de comunicació amb memòria distribuïda amb la qual les rutines de pas de missatges de nivell baix , els beneficis de l’estandardització son molt notoris. La principal avantatge al establir un estàndard per el pas de missatges és la portabilitat i el ser fàcil d’usar. MPI-1 va aparèixer al 1994 i el MPI-2 al 1997, aquest apunta a ampliarse a altres àrees de programació distribuïda.

3.2 QUÈ ÉS MPI? MPI és una interfície de pas de missatge que representa un esforç prometedor de millorar la disponibilitat d’un software eficient i portable per satisfer les necessitats actuals en la computació amb funcions contingudes a una biblioteca de pas de missatges dissenyada per a ser utilitzada en programes que explotin l’existència de múltiples processadors.

Aquesta interfície permet una implementació optimitzada en qualsevol sistema en paral·lel, ens permet programar de manera natural amb qualsevol algoritme en paral·lel.

La interfície MPI té com objectiu proporcionar topologia virtual, sincronització i la funcionalitat de la comunicació entre un conjunt de processos de manera independent del llenguatge. Els programes MPI sempre treballen amb processos, però els programadors més comunament es refereixen als processos com els processadors.

L’objectiu de MPI és desenvolupar un estàndard per poder se àmpliament utilitzat que permeti escriure programes utilitzant el pas de missatges. Per tant, el que volem que ens aporti aquest estàndard és que sigui pràctic, eficient i flexible.

A continuació mostrarem els objectius bàsics de MPI: o Dissenyar una API (Interfície de Programació d’Aplicacions). o Fer eficient la comunicació. o Permetre que les aplicacions puguin utilitzar-se en ambients heterogenis.

o o o

Proveir una interfície de comunicació confiable.

No diferir significativament d’algunes implementacions.

Definir una interfície implementable en plataformes de diferents proveïdors sense tindre que fer canvis significatius.

3.3 EXECUCIÓ DEL MPI Amb MPI també ens trobem amb diferents processos per execució. En aquest cas però, el número de processos que necessitem per realitzar l’execució, s’assigna abans de l’execució del programa, i no es creen processos addicionals mentre la aplicació s’executa. Cada procés que ens trobem del MPI se l’anomena rank, aquest és l’identificador de cada procés. El rang va de 0 a p-1, on p tenim que és el número de total de processos. El control de l’execució del programa es realitza mitjançant la variable rank. Aquesta variable ens permet determinar quin procés s’està executant en qualsevol part determinada del codi.

Hi ha un altre variable important que es diu comunicator (comunicador). Aquest podríem dir que és una col·lecció de processos que poden enviar missatges uns als altres. El comunicator bàsic és conegut com MPI_COMM_WORLD i es defineix amb el llenguatge C. MPI_COMM_WORLD agrupa tots els processos actius durant l’execució d’una aplicació. Les crides es divideixen en quatre classes: 1. Crides utilitzades per inicialitzar, administrar i finalitzar comunicacions. Aquestes crides permeten inicialitzar la biblioteca de pas de missatges.

Identificar el número de processos (size) i el rang dels processos (rank).

2. Crides utilitzades per transferir dades entre un parell de processos. Aquesta classe inclou operacions de comunicació punt a punt per diferents tipus d’activitats d’enviament i recepció.

3. Crides per transferir dades entre varis processos.

Són conegudes com operacions grupals.

Proveeixen operacions de comunicacions entre grups de processos.

4. I per últim, però no per això menys important, crides utilitzades per crear tipus de dades definides per l’usuari. Aquesta proveeix flexibilitat en la construcció d’estructures de dades complexa.

3.3.1

COMUNICACIÓ PUNT A PUNT

El que es coneix com a comunicació punt a punt és un mecanisme de pas de missatge. Aquest mecanisme és molt simple; Tenim un conjunt de processos, i el que passa amb aquest mecanisme, és que un parell d’ells, es comunica mitjançant enviar i rebre missatges, com a la imatge que trobem a l’esquerra. En aquesta imatge trobem una petició de transmissió. Quan aquesta esta acceptada, li diem acceptació de la transmissió. Un cop acceptades comença a enviar dades de buffer a d’usuari a buffer d’usuari. La majoria de constructors

de MPI estan construïts amb operacions de comunicació punt a punt. Per això és important entendre aquest concepte per poder entendre com funciona el MPI. MPI té un conjunt de funcions per enviar i rebre missatges.

Aquestes son les que ens permeten la comunicació entre dades de cert tipus, a través d’una etiqueta associada anomenada tag.

També és necessari saber el tipus de dades amb les que tractem, per fer més heterogènia la seva funcionalitat. El tipus de les dades ens aporta una informació per poder realitzar conversacions en la representació quan s’envien dades d’una arquitectura a l’altre. En canvi, l’etiqueta (tag), és molt útil pel receptor. Ja que aquest pot seleccionar un missatge en particular si és el que li va bé.

Per poder enviar i rebre missatges, s’ha de tenir en compte que estan involucrats la informació dels processos, ja que necessitem saber la informació que ens aporten aquests processos. Quan rebem un procés, volem saber l’emissor i el contingut de la informació. Com ho ha de fer el receptor per saber aquesta informació?

El que fa servir MPI per enviar dades i guanyar portabilitat son els següents: o

Per poder saber què enviem, especificarem les dades a enviar amb tres camps: direcció d’inici, tipus de dades i comptador. On tipus de dades pot ser: -

Elemental. Tots els tipus de dades de C i Fortran.

-

Modificar contínuament el tipus de dades.

-

Blocs dispersos de tipus de dades.

-

Modificacions indexades de blocs de tipus de dades.

-

Estructures generals.

o

Els tipus de dades són construïts recursivament.

o

Les especificacions de tipus comunicacions heterogènies.

o

Eliminació de la longitud en favor del comptador.

de

dades

permeten

Les funcions bàsiques de MPI són les de enviar i les de recepció bloquejat, que amb el llenguatge serien MPI_Send i MPI_recv. Els enviaments MPI estan dissenyats per poder aconseguir el màxim rendiment possible.

En aquesta imatge veiem la operació sendrecieve (enviarrebre). On espera a que la petició sigui acceptada pel receptor, llavors envia i espera al buffer d’entrada i quan el té el receptor, també ha d’esperar al seu buffer, envia les dades i llavors fa l’operació que hagi de fer.

MPI_Send, té dos comportaments possibles dependent de la mida del missatge. Una és guardar el missatge en un buffer i

retornar-la immediatament, i l’altre, és esperar a que el procés del destí comenci a rebre. La mida de missatge pel qual això passa depèn de la implementació i és molt variable.

Dins d’aquesta estructura hi trobem els deadlocks, ue són producte de quan un procés queda esperant un missatge que no rebrà mai.

També tenim més funcions com ara MPI_SOURCE, MPI_TAG i MPI_ERROR. Aquests camps contenen el l’emissor, l’etiqueta que em comentat abans i si hi ha hagut cap error, respectivament.

3.3.2

COMUNICACIÓ COL·LECTIVA

En moltes aplicacions de MPI es necessita la comunicació col·lectiva. Ja que molts cops és necessari enviar un conjunt de dades a molts processos a l’hora. També ens podem trobar amb el cas contrari, el de rebre a un únic procés dades de varis emissors. I aquestes funcions ens les permeten les comunicacions col·lectives, ja que ens concedeixen la transferència de dades entre tots els processos que pertanyen a un grup específic. Així doncs, en aquest apartat ja no parlarem d’etiquetes, sinó que en canvi, parlarem de comunicadors.

Podem veure tres classes d’operacions col·lectives: - Sincronització. Barreres per sincronitzar.

- Moviment (transferència) de dades.

Operacions per difondre, recol·lectar i espaiar.

- Càlculs col·lectius. Operacions per reducció global, com operacions matemàtiques (sumes, màxim, mínim, etc.) definides per l’usuari.

Totes les funcions excepte la de difusió, tenen dues variants. Una en la qual totes les dades transferides son de la mateixa mida (homogeni) i una altre on cada ítem de dades pot tindre una mida diferent (vector).

Algunes d’aquestes funcions, com la de difusió i recol·lecció, tenen un procés originador o un procés receptor, en aquest procés s’acostuma a anomenar arrel (root).

Algunes de les funcions d’aquesta comunicació son les següents: MPI_BARRIER. Atura l’execució de cada procés que la crida fins que tots els processos inclòs el grup associat a comm la hagin cridat.

MPI_BCAST. Transmet el missatge del procés identificat com root a tots els processos del grup.

MPI_GATHER. Fa que cada procés, incloent el root enviï el contingut del seu buffer d’enviament (inbuf) al procés root.

El procés root rep els missatges i els emmagatzema amb ordre (segons el rang del emissor) en el buffer de recepció (outbuf).

MPI_SCATTER. És la operació inversa al MPI_Gather. El procés root enviarà a cada procés un tros del contingut del buffer d’enviament, començant des de la direcció inicial del mateix buffer. Es desplaçarà una quantitat (incount) per realitzar el següent enviament.

MPI_REDUCE. Combina els elements previstos al buffer d’entrada (inbuf) de cada procés en el grup, utilitzant la operació op i retorna el valor combinat al buffer de sortida

(outbuf) del procés root. L’ordre de avaluació canònica de una reducció està determinada pel rang dels processos.

MPI_ALLREDUCE. Es retorna el valor als buffer de sortida de cada un dels processos que intervenen.

3.3.3

TRANSFERÈNCIA

DE

DADES

DISPERSES

O

HOMOGÈNIES

En algunes aplicacions, és necessari transferir dades no homogènies com les estructures (registres) o que no estan contigus a la memòria com les seccions de modificacions. Lo ideal es tindre un mecanisme que ens permeti aquestes transferències sense la necessitat d’utilitzar grans quantitats de missatges. Per aconseguir això MPI proveeix dos esquemes: 1.

L’usuari pot definir tipus de dades derivades, que especifiquin dissenys de dades generals. Aquests nous tipus de dades poden ser utilitzats en les funcions de comunicació de MPI en lloc dels tipus de dades bàsics predefinits.

2.

El procés que envia pot explícitament empaquetar dades no contigües en un buffer contigu i desprès enviar-lo. Mentre que el procés receptor desempaqueta les dades de un buffer contigu per emmagatzemar-los en localitzacions no contigües.

4.

AVANTATGES I INCOVENTIENTS. OPENMP I MPI

Avantatges i inconvenients de OpenMP: Avantatges: o És més fàcil de programar i debugar que MPI. o Les directives poden ser afegides incrementalment – gradual paral·lelització. o Es pot seguir executant el programa com un codi o El codi és més fàcil d’entendre i potser més fàcil de mantenir.

Inconvenients: o Només es pot executar amb memòria compartida. o Requereix un compilador que suporti OpenMP. o Normalment utilitzat per bucles de paral·lelització.

Avantatges i inconvenients de MPI: Avantatges: o S’executa tant amb memòria compartida com privada. o Pot ser més utilitzat en més problemes que OpenMP. o Cada procés té la seva pròpia variable local. o Els ordinadors de memòria privada són menys costosos que els ordinadors de gran memòria compartida.

Inconvenients: o Requereix més canvis de programació, és difícil de mantenir. o Pot ser més difícil de debugar. o La interpretació és limitada per la xarxa de comunicació entre els nodes.

5.

EXEMPLE OPENMP I MPI

Per a poder mostrar com funcionen d’aquestes interfícies, farem servir un exemple de com calcularíem el número PI en cadascuna d’elles.

En OpenMP: #include <omp.h> #include <stdio.h> #include <stdlib.h> int main (int argc, char *argv[]) { int nthreads, tid; int i, INTERVALS; double n_1, x, pi = 0.0; INTERVALS=128000; /* Fork a team of threads giving them their own copies of variables */ #pragma omp parallel private(nthreads, tid) { /* Obtain thread number */ tid = omp_get_thread_num(); printf("Hello from thread = %d\n", tid); /* Only master thread does this */ if (tid == 0) { nthreads = omp_get_num_threads(); printf("Number of threads = %d\n", nthreads); } } /* All threads join master thread and disband */ n_1 = 1.0 / (double)INTERVALS; /* Parallel loop with reduction for calculating PI */ #pragma omp parallel for private(i,x) shared (n_1,INTERVALS) reduction(+:pi) for (i = 0; i < INTERVALS; i++) { x = n_1 * ((double)i - 0.5); pi += 4.0 / (1.0 + x * x); } pi *= n_1; printf ("Pi = %.12lf\n", pi); } En MPI: #include <stdio.h> #include <mpi.h> int main(int argc, char *argv[]) { int numprocs, rank; int i, iglob, INTERVALS, INTLOC; double n_1, x; double pi, piloc; MPI_Init(&argc, &argv); MPI_Comm_size(MPI_COMM_WORLD, &numprocs); MPI_Comm_rank(MPI_COMM_WORLD, &rank); INTERVALS=128000; printf("Hello from MPI task= %d\n", rank); MPI_Barrier(MPI_COMM_WORLD); if (rank == 0) { printf("Number of MPI tasks = %d\n", numprocs); } INTLOC=INTERVALS/numprocs; piloc=0.0;

n_1=1.0/(double)INTERVALS; for (i = 0; i < INTLOC; i++) { iglob = INTLOC*rank+i; x = n_1 * ((double)iglob - 0.5); piloc += 4.0 / (1.0 + x * x); } MPI_Reduce(&piloc,&pi,1,MPI_DOUBLE,MPI_SUM,0,MPI _COMM_WORLD); if (rank == 0) { pi *= n_1; printf ("Pi = %.12lf\n", pi); } MPI_Finalize(); } 6. CONCLUSIÓ Per concloure el cas del OpenMP, podem dir que l’ús d’aquesta interfície és utilitzada per afegir concurrència als programes mitjançant paral·lelisme amb una memòria compartida. Pom dir doncs, que la paral·lelització utilitzant OpenMP és simple, no necessita moltes modificacions al programa i en general dóna molts bons resultats.

Hem vist també, que l’ús de l’MPI és molt eficaç i ens proporciona tot el que es van proposar els seus creadors; que eren que fos: pràctic, eficient i flexible. A més, no tenim la limitació de només poder-ho usar als computadors de memòria compartida, sinó que aquesta limitació no la tenim, però és molt més difícil, com ja hem comentat abans, els canvis de programació.

Per tant, podem concloure, que tot té els seus avantatges i inconvenients, però que a l’hora d’estar estructurat podríem dir que ho esta més bé el MPI. BIBLIOGRAFIA [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]

http://lisidi.cs.uns.edu.ar/chaco/Trabajos/OPENMP.pdf http://www.arcos.inf.uc3m.es/~ii_ac2/04-05/OpenMP_curso.pdf http://en.wikipedia.org/wiki/Openmp#OpenMP_clauses http://en.wikipedia.org/wiki/Openmp http://es.wikipedia.org/wiki/OpenMP http://mmc.geofisica.unam.mx/edp/HPC/MPI/mpiBasico1.pdf http://www.greatlakesconsortium.org/events/scaling/files/openmp09.pdf http://www.dartmouth.edu/~rc/classes/intro_mpi/parallel_prog_compare .html https://computing.llnl.gov/tutorials/openMP/#Introduction http://msdn.microsoft.com/en-us/library/0ca2w8dk.aspx http://msdn.microsoft.com/en-us/library/2kwb957d.aspx http://en.wikipedia.org/wiki/Message_passing http://en.wikipedia.org/wiki/Message_Passing_Interface http://es.wikipedia.org/wiki/MIMD http://es.wikipedia.org/wiki/Paralelismo_(Inform%C3%A1tica) http://openmp.org/wp/ http://openmp.org/wp/2011/07/openmp-31-specification-released/ http://www.compunity.org/ http://beige.ucs.indiana.edu/I590/node54.html http://beige.ucs.indiana.edu/I590/node56.html http://webdelprofesor.ula.ve/ingenieria/hhoeger/Introduccion_MPI.pdf http://www.slideshare.net/unlopez/introduccion-a-mpi