Im offiziellen Forum der FDS-Entwickler ist über die Frage nach Plänen zur Nutzung von GPGPU mittels OpenCL in zukünftigen FDS-Versionen eine interessante Diskussion zum aktuellen Stand des Themas und möglichen Strategien zur Nutzung in FDS in Gang gekommen.
Einen sehr guten Ãœberblick über die aktuellen Probleme, die erforderliche Vorarbeit und die Chancen bietet der Beitrag von Christian Rogsch.Â
Zusammenfassend kann man das Thema durchaus als verfolgenswert bezeichnen. Christian Rogsch arbeitet mittel bis langfristig an einer konsequenteren Parallelisierung des Codes, die seiner aktuellen Arbeit mit OpenMP zukommen soll. Sollten zukünftige Compiler-Versionen die Nutzung von GPGPU mittels Compilerdirektiven aus Fortran-Code weiter vereinfachen und durchgängig nutzbar machen, steht einer deutlichen Leistungssteigerung grundsätzlich nichts mehr im Weg.
Hallo zusammen,
da es in diesem Beitrag meiner Ansicht nach etwas „schwammig“ formuliert wurde mit der Nutzung von OpenCL, möchte ich das Thema nochmal soweit es geht klarstellen (kann natürlich auch sein, dass es an meinem Post im FDS-Forum liegt, dass der auch nicht so ganz präziese war). Wie auch immer:
Es ist nicht geplant OpenCL oder welche andere Sprache auch immer in den FDS-Code zu implementieren. Ich möchte hier auf das Statement aus der FDS-Roadmap verweisen:
„Potential Task: Convert the source code file isob.c to Fortran 90/95 so that FDS can be 100% Fortran. This is not a high priority item, but if someone were handy in both C and Fortran and could do this easily, it would make it much easier to port FDS to other platforms.“
Ziel ist es bei FDS komplett platformunabhängig zu sein, und das auch nur in einer Sprache, also Fortran. Es ist nicht geplant, irgendwelche nicht-standardisierten Sprachen wie CUDA oder ähnlich zu nutzen, da die den Code nicht verbessern. Die einzige und im Moment akzeptable Lösung ist die Implementierung einer GPGPU-Nutzung mittels Compilerdirektiven wie es PGI anbietet. Hier wird der jeweilige Fortran Code in den CUDA-C Code übersetzt (macht der Compiler) und dann kompiliert. Diese Möglichkeit ist deshalb akzeptabel, weil sie nur als Compilerdirektive in den Code mit einfließt, d. h. wird der Code mit welchem Compiler auch immer kompiliert, dann sind das für diesen Compiler nur Kommentare, die nicht mitkompiliert werden. Der Code bleibt somit in Fortran.
Wichtig ist, dass der Code auf jedem Rechner laufen muss, der einen Fortran-Compiler mit sich bringt. Solange es keinen Standard wie OpenMP bei der Nutzung von Graphikkarten gibt, kann nur der PGI-Lösungsansatz gewählt werden, da der den Code nicht negativ beeinflusst. Subroutinen in OpenCL oder CUDA-Fortran (welch ein Grauß, der Name) sind nicht möglich, da sie entweder nicht einem offenen Standard entsprechen oder nicht in Fortran geschrieben sind.
Beste Grüße
Christian Rogsch
Eine kleine Anmerkung, falls es in meinem Post auf der FDS-Seite nicht genau rüberkam bzw. es hier auch nicht klar (zumindest für mich) ausgesagt wird: Es ist nicht geplant, OpenCL oder irgendwas anderes zu nehmen bzw. irgendwelche Subroutinen in OpenCL zu schreiben und die dann einzubinden. Ich möchte deshalb auf die FDS-RoadMap verweisen, dort steht:
\Potential Task: Convert the source code file isob.c to Fortran 90/95 so that FDS can be 100% Fortran. This is not a high priority item, but if someone were handy in both C and Fortran and could do this easily, it would make it much easier to port FDS to other platforms.\
Wenn überhaupt die Nutzung von GPUs in Frage kommt, dann aktuell nur im Sinne von Compilerdirektiven wie es PGI ermöglicht. Das heißt, dass der Compiler (oder welches Programm auch immer) die Konvertierung machen muss (und zwar richtig), der Quellcode an sich wird in Fortran bestehen bleiben. Da die Compilerdirektiven für andere Compiler ja nur \Kommentare\ sind, haben die keinen Einfluss auf das Ergebnis und beeinflussen somit nicht den Code.
Deshalb kein OpenCL, CUDA, FireStream oder was auch immer, nur im Sinne von Compilerdirektiven, da der Code an sich
1) Offenen Standards genügen muss (CUDA ist kein offener Standard)
2) in Fortran bleibt
3) Platformunabhängig sein muss.
Compilerdirektiven können dann platformspezifisch sein, da sie sich im Falle einer \Standardkompilierung\ nicht auf den Quellcode auswirken. Mer ist aber nicht geplant.