Was ist die am häufigsten verwendete Programmiersprache im Hochleistungsrechnen? Und warum? [geschlossen]

Ich glaube, dass viel Fortran in HPC verwendet wird, aber ich bin mir nicht sicher, ob dies nur aus alten Gründen geschieht.

Funktionen moderner Programmiersprachen wie Garbage Collection oder Laufzeit-Polymorphismus sind für HPC nicht geeignet, da die Geschwindigkeit eine Rolle spielt.

Irgendwelche Gedanken?

Ich habe viel Java für HPC in Bereichen gesehen, in denen (1) wenig Legacy-Code vorhanden ist und (2) Entwicklungszeit und Codequalität eine Rolle spielen. Typische Anwendungsbereiche sind Finanzen, Data Mining oder Bioinformatik.

Es hängt wirklich von der Anwendung ab (es gibt ein Leben außerhalb der linearen Algebra), aber die Leistung aktueller JVMs ist häufig mit C-Code vergleichbar. Manchmal schneller, wenn die JVM zur Laufzeit clevere Optimierungen durchführen kann, die statische Compiler (C, Fortran) nicht können. Und auf jeden Fall schneller, wenn es viel symbolisches Rechnen gibt.

Bei einer festgelegten Zeit für die Programmentwicklung ist der resultierende Java-Code durchweg schneller als C-Code. HPC in Java ist auf jeden Fall sinnvoll, wenn Code häufig entwickelt oder geändert wird. Ein weiteres wichtiges Merkmal ist die Codemobilität über verschiedene Hardware.

Referenzen finden Sie unter http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Unter der Annahme, dass zwei Adressen eindeutig sind, arbeitet Fortran an einem statischen Analysetool, das ähnliche Optimierungen für Code in Hochsprachen ermöglicht, jedoch ohne das Bit "Bad Things May Happen". Kontaktieren Sie mich bei Interesse.

In meiner jahrelangen Erfahrung vor bis zu 5 Jahren waren es immer Fortran und C. Was am meisten davon abhing, ob die Leute mehr vom Ingenieurswesen oder mehr von der CS-Denkschule stammten (ich weiß nicht, wie ich das besser ausdrücken soll) , okey? :-)

In dem, was wir taten, wurde fast ausschließlich Fortran verwendet.

Nach dem, was ich heute gelesen habe, scheint es mit den neuen Updates für den Standard F2003 / 08 und der Einführung von Co-Arrays wieder an Dynamik zu gewinnen.

Auch ein, wenn nicht etwas voreingenommener Artikel - Die ideale HPC-Programmiersprache

Ich denke, für echte Pedale im Metal ist Fortran die einzige echte Wahl. Die Überlegung ist, dass das Wichtigste für die Ausnutzung von ILP auf niedriger Ebene (Instruction Level Parallism) die Disambiguierung von Speicheradressen ist. Mit den Defacto-Regeln in Fortran kann der Compiler feststellen, dass zwei Adressen eindeutig sind (und daher kann die Reihenfolge von Laden und Speichern oder sogar Speichern und Speichern ausgetauscht werden, ohne dass das Risiko besteht, dass falscher Code generiert wird). C lässt zu viel Spielraum für überlappende Zeiger, damit der Compiler so viel Parallelität auf niedriger Ebene aus dem Code extrahieren kann.

Auch die Array-Ausrichtung, Schreib-Cache-Zeilen und SSE / AVX-Grenzen sind wichtig für die Erzeugung und Ausführung effizienter Schleifen. Wenn Arrays über gemeinsame Blöcke übergeben werden, kann der Compiler / Loader sicherstellen, dass alle Arrays an denselben Adressausrichtungsgrenzen beginnen und effizientere SSE / AVX-Ladevorgänge und -Speicher verwendet werden können. Die neuere Hardware kann nicht ausgerichtete Speicherzugriffe verarbeiten. Da der Speicherzugriff jedoch nicht ordnungsgemäß ausgerichtet ist, führt die teilweise Verwendung von Cache-Zeilen zu einer geringeren Leistung. Gibt es einen Mechanismus, um dies dem Compiler mitzuteilen, selbst wenn ein C-Programmierer alle seine Arrays richtig ausrichtet?

Zusammenfassend sind die beiden wichtigsten Punkte die Unabhängigkeit von Speicheradressen und die Erkennung durch den Compiler, dass die Datenstrukturen, auf die zugegriffen wird, dieselbe "natürliche" Ausrichtung aufweisen, die die Hardware wünscht. Bisher leistet Fortran bei diesen beiden Aufgaben die beste Arbeit.

Nur ein paar Anekdoten. Ich habe selbst noch kein Hochleistungs-Computing gemacht.

Für Berechnungen (Zahlenkalkulation), Fortran und C. Ja, es ist aus Legacy-Gründen:

• Reichliche Verfügbarkeit von gemeinfreiem Quellcode und Rezepten.
• Beide unterstützen MPI .
• Beide Sprachen werden kompiliert.
• Compiler für beide Sprachen werden von allen HPC-Betriebssystemen und -Herstellern bereitgestellt.
• Vektorisierende Compiler sind verfügbar.
• Beides erfordert ein unglaubliches Maß an Optimierungen, um eine hohe Leistung zu erzielen, wenn es auf einen anderen Cluster portiert wird (unterschiedliche Speichergröße, Anzahl der CPUs usw.).
  • Dies erklärt tatsächlich, warum der Open Source Code wichtig ist: Optimierungen sind erforderlich, daher muss das Originalrezept in einer Sprache verfasst sein, die für manuelle Optimierungen geeignet ist.

Der aktuelle Trend für die Zahlenverarbeitung besteht darin, Programmgeneratoren zu schreiben, die das Optimieren des Quellcodes automatisieren, um die Leistung angesichts der Cluster-Eigenschaften zu optimieren. Diese Generatoren geben häufig in C aus.

Ein zweiter Trend ist das Schreiben in einem speziellen Dialekt von C für bestimmte GPUs oder Cell BE.

Für nicht numerische Arbeiten, wie z. B. Programme, die Daten aus einer Datenbank verarbeiten (aber nicht aus der Datenbank selbst), ist es viel billiger, auf Clustern von "Commodity" -Maschinen ohne die teuren angepassten Netzwerkgeräte zu laufen. Dies wird üblicherweise als "High Throughput Computing" bezeichnet. Und Python ist hier die erste Sprache (mit dem berühmten Map Reduce). Vor Python können Stapelverarbeitungsprojekte in einer beliebigen Sprache geschrieben werden und werden normalerweise von Condor versendet .

Ich habe an SEHR rechenintensivem Code in (keuchen!) C # gearbeitet.

Ich erstelle eine GPGPU-Implementierung von FDTD für die optische Modellierung. Auf einem kleinen Cluster (128 Prozessoren) dauern viele unserer Simulationen Wochen. Die GPU-Implementierungen werden jedoch in der Regel 50-mal schneller ausgeführt - und das auf einer NVidia-Karte für Endverbraucher. Wir haben jetzt einen Server mit zwei GTX295-Dual-Prozessor-Karten (mehrere hundert Kerne) und bekommen bald einige Teslas.

Wie bezieht sich das auf Ihre Sprache? Genauso wie der zuvor verwendete C ++ - FDTD-Code CPU-gebunden war, sind diese GPU-gebunden, sodass der ( sehr kleine) Leistungsunterschied zwischen verwaltetem und nativem Code nie ins Spiel kommt. Die C # -App fungiert als Dirigent, der OpenCL-Kernel lädt, Daten zu und von den GPUs überträgt, die Benutzeroberfläche bereitstellt, Berichte erstellt usw. - alles Aufgaben, die in C ++ nerven.

In den vergangenen Jahren war der Leistungsunterschied zwischen verwaltetem und nicht verwaltetem Code so groß, dass es sich manchmal lohnte, das schreckliche Objektmodell von C ++ in Kauf zu nehmen, um ein paar Prozent mehr Geschwindigkeit zu erzielen. Heutzutage überwiegen die Entwicklungskosten von C ++ gegenüber C # die Vorteile für die meisten Anwendungen bei weitem.

Außerdem hängt der größte Teil Ihres Leistungsunterschieds nicht mit Ihrer Sprachauswahl zusammen, sondern mit den Fähigkeiten Ihres Entwicklers. Vor einigen Wochen habe ich eine einzelne Divisionsoperation aus dem Inneren einer dreifach verschachtelten Schleife (3D-Array-Traversal) verschoben, wodurch die Ausführungszeit für eine bestimmte Berechnungsdomäne um 15% reduziert wurde. Dies ist ein Ergebnis der Prozessorarchitektur: Die Aufteilung ist langsam. Dies ist eines der Gesichter, die Sie nur irgendwo aufgegriffen haben müssen.

Fortran ist am häufigsten anzutreffen, hauptsächlich aufgrund von Legacy (die Leute verwenden immer noch alten Code) und Vertrautheit (die meisten Leute, die HPC verwenden, sind mit anderen Arten von Sprachen nicht vertraut).

Funktionen moderner Programmiersprachen wie Garbage Collection oder Laufzeit-Polymorphismus sind für HPC nicht geeignet, da die Geschwindigkeit eine Rolle spielt.

Das ist im Allgemeinen nicht wahr. Klassische HPC führten meist lineare Algebra mit maschinengenauen Zahlen durch. Moderne HPC-Systeme verwenden jedoch zunehmend Supercomputer für eine breitere Palette von Funktionen, z. B. symbolische Berechnungen mit beliebigen mathematischen Ausdrücken anstelle von maschinengenauen Zahlen. Dadurch ergeben sich für die von Ihnen verwendeten Tools ganz andere Eigenschaften, und es ist nicht ungewöhnlich, andere Programmiersprachen als Fortran zu verwenden, da die symbolische Berechnung ohne GC und andere Arten von Optimierungscompilern wie den OCaml-Optimierungs-Pattern-Match-Compiler unerschwinglich schwierig sein kann.

Lesen Sie zum Beispiel diesen Artikel von Fischbacher et al. die besagt, "die Autoren haben starken Grund zu der Annahme, dass dies die größte symbolische Berechnung sein könnte, die bisher durchgeführt wurde".

Fortran, aus guten und aus weniger guten Gründen. Ein guter Grund dafür ist, dass es umfangreiche Bibliotheken (BLAS, LAPACK) mit bewährten Unterprogrammen gibt, die alle in Fortran geschrieben sind (obwohl diese von C und C ++ aus aufgerufen werden können).

Ein nicht ganz so guter Grund ist der vermeintliche Leistungsvorteil von Fortran gegenüber C / C ++. Optimierer sind ziemlich gut, und nur wenige Leute wissen, dass der Vorteil der Optimierung eines Codeteils proportional zu dem Prozentsatz der Zeit ist, in der der Code ausgelastet ist.

Ein weiterer nicht so guter Grund ist eine kulturelle Kluft zwischen CS- und Nicht-CS-Programmierern. Wissenschaftliche Programmierer lernen in Fortran schlechte Gewohnheiten und sehen auf die CS-Programmierer und die schlechten Gewohnheiten, die ihnen beigebracht wurden, und auf die ersteren herab.

Grundsätzlich sind alle Programme, die die eigentliche Arbeit der Zahlenverarbeitung erledigen, immer noch FORTRAN (die alten blas, Lapack, Arnoldi usw. werden immer noch verwendet) C ++.

Die Komplexität der Simulation beinhaltet einen großen Code. Wenn Sie einen Vorteil aus dem Schreiben ziehen möchten, müssen Sie ihn wiederverwendbar machen. Auch die verwendeten Konzepte sind sehr komplex geworden. Es ist fast ein Wahnsinn, diese Informationen mit FORTRAN darzustellen. Hier kommt C ++ ins Spiel, da es von Natur aus objektorientiertes Design unterstützt. Laufzeitpolymorphismus wird jedoch selten bevorzugt. Stattdessen wird fast immer der statische Polymorphismus verwendet (der in C ++ mit Template-Metaprogrammierung implementiert ist).

Außerdem sind die Compiler jetzt wirklich gut, weshalb den Compilern viel Optimierungsarbeit überlassen bleibt.

Es gibt zwei Arten von Problemen, die bei HPC-Anwendungen behoben werden müssen: Die eine ist die Zahl, die sich selbst zermahlt, und die andere verwaltet die Berechnungen. Die erste Methode wird normalerweise mit in Fortran, C oder C ++ geschriebenem Code angegangen, da die Geschwindigkeit und die Tatsache, dass bereits viele wissenschaftliche Algorithmen in diesen Sprachen geschrieben sind, ausschlaggebend sind. Die Steuerung von Berechnungen wird bequemer in höheren Sprachen implementiert. Python ist die bevorzugte "Klebesprache" für die Verarbeitung von Anwendungslogik und das Aufrufen von Erweiterungen, die in kompilierten Sprachen implementiert sind. Java wird häufig in Projekten verwendet, in denen die Verwaltung von Netzwerken und verteiltem Computing unerlässlich ist.