nicht sicher, was FREIGEGEBEN werden soll oder PRIVAT in der openmp-Schleife

Die goldene Regel von OpenMP ist, dass alle Variablen (mit einigen Ausnahmen), definiert sind, die in einem äußeren Umfang, geteilt werden standardmäßig in der parallelen region. Da in Fortran vor 2008 gibt es keine lokalen Bereiche (d.h. es gibt keine BLOCK ... END BLOCK in früheren Versionen), alle Variablen (außer threadprivate) geteilt werden, das ist sehr natürlich für mich (im Gegensatz zu Ian Bush, ich bin kein großer fan der Verwendung von default(none) und dann redeclaring die Sichtbarkeit aller 100+ lokale Variablen in verschiedenen komplexen wissenschaftlichen codes).

Hier ist wie Sie bestimmen die sharing-Klasse für jede variable:

• N - geteilt, denn es sollten die gleichen in allen threads und Sie nur Lesen seinen Wert.
• ii - es wird der Zähler der Schleife, unterliegen einer worksharing-Richtlinie, so seine sharing-Klasse ist vorbestimmt zu sein private. Es tut nicht weh, ausdrücklich erklären, es in einem PRIVATE - Klausel, aber das ist nicht wirklich notwendig.
• jj - Zählvariable einer Schleife, die nicht Gegenstand eines worksharing-Richtlinie, daher jj sollte private.
• X - geteilt, da alle threads verweisen und nur Lesen zu können.
• distance_vector - offensichtlich sollte private wie jeder thread arbeitet auf verschiedenen Paaren von Teilchen.
• distance, distance2, und coff - dito.
• M - der freigegeben werden soll, aus den gleichen Gründen wie X.
• PE - fungiert als eine Akkumulator-variable (ich glaube, das ist die potentielle Energie des Systems) und sollte ein Gegenstand von einer Reduktion operation, d.h., sollte in einen REDUCTION(+:....) - Klausel.
• A - das ist heikel. Es könnte entweder gemeinsame und updates zu A(jj,:) geschützt mit Synchronisation baut, oder verwenden Sie die Reduktion (OpenMP ermöglicht Reduktionen über array-Variablen in Fortran anders als in C/C++). A(ii,:) nie geändert werden, um mehr als einen thread, damit es nicht eine Besondere Behandlung benötigen.

Mit Reduktion über A im Ort, jeder thread bekommen würde, seine private Kopie A - und dies könnte ein memory hog, obwohl ich bezweifle, verwenden Sie diesen direkten O(N²) simulation code zur Berechnung von Systemen mit sehr große Anzahl von Teilchen. Es gibt auch einen bestimmten overhead in Zusammenhang mit der Reduzierung Umsetzung. In diesem Fall müssen Sie einfach hinzufügen A auf die Liste der REDUCTION(+:...) - Klausel.

Mit synchronisieren Konstrukte haben Sie zwei Möglichkeiten. Entweder Sie verwenden die ATOMIC konstruieren oder die CRITICAL konstruieren. Als ATOMIC ist nur anwendbar auf Skalare Kontexten, Sie würde zu "unvectorise" die Zuordnung Schleife und gelten ATOMIC zu jeder Anweisung separat, z.B.:

!$OMP ATOMIC UPDATE
A(jj,1)=A(jj,1)+(M(ii)/coff)*(distance_vector(1))
!$OMP ATOMIC UPDATE
A(jj,2)=A(jj,2)+(M(ii)/coff)*(distance_vector(2))
!$OMP ATOMIC UPDATE
A(jj,3)=A(jj,3)+(M(ii)/coff)*(distance_vector(3))

Sie können auch schreiben dies als eine Schleife - vergessen Sie nicht zu erklären, den Schleifenzähler private.

Mit CRITICAL es gibt keine Notwendigkeit, unvectorise der Schleife:

!$OMP CRITICAL (forceloop)
A(jj,:)=A(jj,:)+(M(ii)/coff)*(distance_vector)
!$OMP END CRITICAL (forceloop)

Benennung von kritischen Regionen ist optional und ein bisschen unnötig, in diesem speziellen Fall, aber im Allgemeinen ist es erlaubt zu trennen unabhängigen kritischen Regionen.

Welche ist schneller? Abgerollt mit ATOMIC oder CRITICAL? Es hängt von vielen Dingen ab. In der Regel CRITICAL ist viel langsamer, da es oft mit Funktionsaufrufen die OpenMP-Laufzeitumgebung während der atomic-Schritten, zumindest auf x86-Systemen umgesetzt werden gesperrt, neben Anweisungen. Sie sagen oft: YMMV.

Zu rekapitulieren, eine funktionierende version deiner Schleife sollte so etwas wie:

!$OMP PARALLEL DO PRIVATE(jj,kk,distance_vector,distance2,distance,coff) &
!$OMP& REDUCTION(+:PE)
do ii=1,N-1
   do jj=ii+1,N
      distance_vector=X(ii,:)-X(jj,:)
      distance2=sum(distance_vector*distance_vector)
      distance=DSQRT(distance2)
      coff=distance*distance*distance
      PE=PE-M(II)*M(JJ)/distance
      do kk=1,3
         !$OMP ATOMIC UPDATE
         A(jj,kk)=A(jj,kk)+(M(ii)/coff)*(distance_vector(kk))
      end do
      A(ii,:)=A(ii,:)-(M(jj)/coff)*(distance_vector)
   end do
end do
!$OMP END PARALLEL DO

Ich bin davon ausgegangen, dass Ihr system ist 3-dimensional.

Mit all dies sagte, ich, die zweite Ian Bush, dass Sie brauchen, um zu überdenken, wie position und Beschleunigung Matrizen im Speicher angeordnet sind. Die richtige cache-Nutzung könnte steigern Sie Ihre code und würde auch ermöglichen, dass für bestimmte Operationen, z.B. X(:,ii)-X(:,jj) werden vektorisiert, d.h. implementiert mit Vektor-SIMD-Anweisungen.

InformationsquelleAutor Hristo Iliev