it-swarm-eu.dev

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

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

Funktionen moderner Programmiersprachen wie Garbage Collection oder Laufzeitpolymorphismus sind für HPC nicht geeignet, da die Geschwindigkeit eine Rolle spielt und Sie nicht sicher sind, wo C # oder Java oder C++ hereinkommt).

Irgendwelche Gedanken?

25
Fanatic23

Ich habe viele Java für HPC in Bereichen verwendet, 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 Leben außerhalb der linearen Algebra), aber die Leistung aktueller JVMs entspricht häufig der von C-Code. Manchmal schneller, wenn die JVM zur Laufzeit clevere Optimierungen durchführen kann, die statische Compiler (C, Fortran) nicht können. Und definitiv schneller, wenn es viele symbolische Berechnungen gibt.

Bei einer festen 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.

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

In Bezug auf die Fortran-Annahme, dass zwei Adressen eindeutig sind, arbeiten wir 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.

11
Patrick Viry

In meiner jahrelangen Erfahrung bis vor 5 Jahren waren es immer Fortran und C. Was hauptsächlich davon abhing, ob die Leute mehr aus dem Ingenieurwesen oder mehr aus der CS-Denkschule stammten (I. Ich weiß nicht, wie ich das besser ausdrücken soll, okey ?: -)

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

Nach dem, was ich heutzutage gelesen habe, scheint es mit den neuen Aktualisierungen des Standards F2003/08 und der Einführung von Co-Arrays wieder an Dynamik zu gewinnen.

Auch ein, wenn auch nicht etwas voreingenommener Artikel - The Ideal HPC Programming Language

31
Rook

Ich denke, für ein echtes Pedal auf dem Metall ist Fortran die einzig richtige Wahl. Der Grund dafür 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 Ladevorgängen 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.

Außerdem sind die Array-Ausrichtung, w.r.t-Cache-Zeilen und SSE/AVX-Grenzen 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-Lade- und Speichervorgänge verwendet werden können. Die neuere Hardware kann nicht ausgerichtete Speicherzugriffe verarbeiten. Da der Speicherzugriff jedoch nicht richtig 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 Probleme die Unabhängigkeit der 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.

16
Omega Centauri

Nur eine anekdotische Notiz. Ich habe selbst kein Hochleistungsrechnen durchgeführt.

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

  • Ausreichende 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 Anbietern bereitgestellt.
  • Vectorizing-Compiler sind verfügbar.
  • Beides erfordert verrückte Anpassungen, 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 geschrieben werden, die für manuelle Optimierungen geeignet ist.

Der aktuelle Trend zur Zahlenkalkulation besteht darin, Programmgeneratoren zu schreiben, die die Optimierung des Quellcodes automatisieren, um die Leistung angesichts der Cluster-Eigenschaften zu optimieren. Diese Generatoren geben häufig in C aus.

Ein zweiter Trend besteht darin, einen speziellen C-Dialekt für bestimmte GPUs oder Cell BE zu schreiben.

Für nicht numerische Arbeiten, wie z. B. Programme, die Daten aus einer Datenbank (aber nicht aus der Datenbank selbst) verarbeiten, ist die Ausführung auf Clustern von "Commodity" -Maschinen ohne die teuren benutzerdefinierten Netzwerkgeräte viel billiger. Dies wird normalerweise als "High Throughput Computing" bezeichnet. Und Python ist hier die Sprache Nr. 1 (unter Verwendung der berühmten Map Reduce). Vor Python können Stapelverarbeitungsprojekte in jeder Sprache geschrieben werden und werden normalerweise von Kondor .

15
rwong

Ich habe an einem SEHR rechenintensiven Code in (keuch!) C # gearbeitet.

Ich baue eine GPGPU-Implementierung von FDTD für die optische Modellierung. Auf einem kleinen Cluster (128 Prozessoren) dauern viele unserer Simulationen Wochen. Die GPU-Implementierungen laufen jedoch in der Regel etwa 50-mal schneller - 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 Teslas.

Wie hängt das mit Ihrer Sprache zusammen? Genauso wie der C++ - FDTD-Code, den wir zuvor verwendet haben, CPU-gebunden war, sind diese GPU-gebunden, also der ( sehr kleine) Leistungsunterschied von verwaltetem vs nativem Code kommt nie ins Spiel. Die C # -App fungiert als Dirigent - sie lädt OpenCL-Kernel, übergibt Daten an und von den GPUs, stellt die Benutzeroberfläche bereit, berichtet 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, sich mit dem schrecklichen Objektmodell von C++ abzufinden, um die zusätzlichen paar Prozent der Geschwindigkeit zu erhalten. Heutzutage überwiegen die Entwicklungskosten von C++ gegenüber C # bei weitem die Vorteile für die meisten Anwendungen.

Außerdem wird der größte Teil Ihres Leistungsunterschieds nicht von Ihrer Wahl der Sprache herrühren, sondern von 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. Das ist ein Ergebnis der Prozessorarchitektur: Die Teilung ist langsam, was eines der Gesichter ist, die Sie nur irgendwo aufgegriffen haben müssen.

4
3Dave

Fortran ist am häufigsten anzutreffen, vor allem 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 Laufzeitpolymorphismus sind für HPC nicht geeignet, da die Geschwindigkeit eine Rolle spielt und Sie nicht sicher sind, wo C # oder Java oder C++ hereinkommt).

Das stimmt im Allgemeinen nicht. Die klassische HPC führte hauptsächlich lineare Algebra mit maschinengenauen Zahlen durch. Moderne HPC verwenden jedoch zunehmend Supercomputer für eine größere Vielfalt von Knirschen, wie symbolische Berechnungen mit beliebigen mathematischen Ausdrücken anstelle von Maschinengenauigkeitszahlen. Dies verleiht den 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 OCamls Optimierungsmuster-Match-Compiler unerschwinglich schwierig sein kann.

Lesen Sie zum Beispiel dieses Papier von Fischbacher et al. , in dem es heißt: "Die Autoren haben starken Grund zu der Annahme, dass dies durchaus möglich ist." die größte symbolische Berechnung sein, die bisher durchgeführt wurde ".

3
Jon Harrop

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

Ein nicht so guter Grund ist der angebliche Leistungsvorteil von Fortran gegenüber C/C++. Optimierer sind ziemlich gut, und nur wenige Leute verstehen, dass der Vorteil der Optimierung eines Codeteils proportional zu dem Prozentsatz der Zeit ist, in der er beschäftigt ist, was in fast allen Codes fast Null ist.

Ein weiterer nicht so guter Grund ist eine Kulturlücke zwischen CS- und Nicht-CS-Programmierern. Wissenschaftliche Programmierer neigen dazu, in Fortran schlechte Gewohnheiten zu lernen und auf die CS-Programmierer und die schlechten Gewohnheiten herabzuschauen sie wurden gelehrt, und die auf die ersteren herabblicken.

3
Mike Dunlavey

Grundsätzlich sind alle Programme, die die eigentliche Arbeit des Zahlenkalkulierens erledigen, immer noch FORTRAN (die alten Blas, Lapack, Arnoldi usw. werden immer noch verwendet) ... Wenn es jedoch um eine übergeordnete Struktur geht ... verwenden die Leute zunehmend C++.

Die Komplexität der Simulation beinhaltet einen riesigen Code. Um einen Nutzen aus dem Schreiben zu ziehen, muss man ihn wiederverwendbar machen. Auch die verwendeten Konzepte sind sehr komplex geworden. Es ist fast 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. Die Leute verwenden stattdessen fast immer den statischen Polymorphismus (der in C++ mit Template-Metaprogrammierung implementiert ist).

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

2
user27946

Es gibt zwei Arten von Problemen, die in HPC-Anwendungen behoben werden müssen: Zum einen die Zahl, die sich selbst zusammensetzt, und zum anderen die Verwaltung von Berechnungen. Der erste wird normalerweise mit Code angegangen, der in Fortran, C oder C++ geschrieben ist, weil er schnell ist und weil bereits viele wissenschaftliche Algorithmen in diesen Sprachen geschrieben sind. Die Steuerung von Berechnungen ist bequemer in höheren Sprachen implementiert. Python ist eine "Klebesprache" der Wahl für die Verarbeitung von Anwendungslogik und Aufruferweiterungen, die in kompilierten Sprachen implementiert sind. Java wird häufig von Projekten verwendet, in denen die Verwaltung von Netzwerken und Distributed Computing ist unerlässlich.

1
j..