Hi Leute, habt Ihr paar gängige Programmiersprachen für die parallele Programmierung parat? Welche sind da am gängigsten und welche sind effizient? Irgendwie finde ich keine eindeutige Liste über gängige parallele Programmiersprachen Danke
was meinst du mit paralleler programmierung? nen neuen thread und die abarbeitung von anderen Dingen darin kannst du in jeder Programmiersprache machen?!
Hallo, als "echte" parallele Programmiersprache habe ich mal mit Occam auf INMOS Transputern gearbeitet. Heute wird das mit allen gängigen Programmiersprachen hauptsächlich C++ und den entsprechenden Erweiterungen OpenCL etc. gemacht. Grüße aus Berlin
VHDL Verilog Die daraus synthetisierte Funktion ist bei der Ausführung in Hardware vollständig nebenläufig (~parallel), sofern man nicht explizit sequentielle Konstrukte einsetzt.
Hi, danke für Eure Antworten. Also kann man leztzendlich mit fast allen gängigen sequentiellen Programmiersprach auf paralleler Ebene programmieren. OpenMP scheint das gängigste zu sein? Was ist zu empfehlen?
kommt darauf an wie "exotisch" die ausgangsprogrammiersprache sein soll ;-) someone schrieb: > C/C++ mit OpenMP/OpenMPI, funktioniert auch z.b. im cluster-betrieb (64 maschinen mit 256 cores und 512GB ram gesamt - und das war nur der teil der über nacht für eine lehrveranstaltung reserviert war) hervorragend, das originale MPI gibt es auch für fortran - von openmpi weiß ich das nicht (ohne nachzuschauen) abc schrieb: > Erlang. als funktionale programmiersprache mit einer etwas höheren einstiegshürde, aber die programmiersprache ist explizit für parallele anwendungen mit (wirklich) light-weight-threads konzipiert.
Hier ist eine gute Übersicht: http://en.wikipedia.org/wiki/List_of_concurrent_and_parallel_programming_languages
Andreas Schweigstill schrieb: > VHDL > Verilog > > Die daraus synthetisierte Funktion ist bei der Ausführung in Hardware > vollständig nebenläufig (~parallel), sofern man nicht explizit > sequentielle Konstrukte einsetzt. Es sind bei diesem Anwendungsfall aber beides keine Programmiersprachen im üblichen Sinne.
Nase schrieb: > Es sind bei diesem Anwendungsfall aber beides keine > Programmiersprachen im üblichen Sinne. Der Threadersteller hat überhaupt keinen Anwendungsfall beschrieben. Und Ansätze wie OpenMP parallelisieren nicht die Programmiersprache, sondern sind nur Mittel zur Verteilung in Mehrprozessorsystemen.
Nase schrieb: > Es sind bei diesem Anwendungsfall aber beides keine > Programmiersprachen im üblichen Sinne. Definiere "üblich". Immerhin handelt es sich eindeutig um Sprachen zur Programmierung. Einzig das Forum "PC-Programmierung" schränkt das Feld entsprechend ein, weil es sich auf Programmung des PCs bezieht. In "FPGA, VHDL & Co." wärs dann andersrum.
:
Bearbeitet durch User
A. K. schrieb: > Immerhin handelt es sich eindeutig um Sprachen zur > Programmierung. Das ist gar nicht ganz so eindeutig. Man spricht gemeinhin ja auch nicht von einem Programm, das man z.B. ins FPGA lädt, sondern von einer Konfiguration. Vielleicht auch, weil man in erster Linie ja mit VHDL&Co. kein Steuerwerk mit einer Sequenz von Befehlen programmiert, welches dann etwa 'ein' Rechenwerk im Prozessor steuert. Sondern weil man mit VHDL eigentlich nur Schalter konfiguriert, um damit irgendwie geartete Logikzellen miteinander zu verbinden. Der Character einer Ablaufsteuerung entfällt also eigentlich komplett. Man müsste sich aus den Logikzellen quasi ein Steuer- und ein Rechenwerk zusammenkonfigurieren... Üblicherweise bezeichnet man VHDL&Co. eher als Beschreibungssprache. HTML ist auch eine Beschreibungs- und keine Programmiersprache. Dass VHDL nebenbei noch Touring-vollständig ist, ist eher ein Nebeneffekt. In VHDL programmiert man letztlich ja auch nicht die Zielplattform (FPGA). Viel mehr programmiert (oder instruiert) man das Synthesewerkzeug. Schleifen in VHDL landen ja auch nicht im FPGA, sondern werden vom Synthesewerkzeug ausgerollt. Wenn man die Definition 'Programmiersprache' am Ziel aufhängt, dann ist VHDL eigentlich keine.
Nase schrieb: > Wenn man die Definition 'Programmiersprache' am Ziel aufhängt, dann ist > VHDL eigentlich keine. Doch. VHDL ist über die Simulation definiert, nicht über die Sythesefähigkeit für Hardware. Letztere ist nur ein (durchaus gewollter!) Nebeneffekt. Außerdem habe ich die Sprachen VHDL und Verilog aufgeführt und nicht die daraus generierten Bitstreams.
:
Bearbeitet durch User
Ja, und? Macht das die beiden Sprachen nun mehr zur Programmiersprache? Die Vereinbarung ist sicherlich unscharf und subjektiv gewachsen, aber sie ist allgemein akzeptiert. VHDL trägt sie sogar im Namen. Es kann nun sinnvoll sein oder nicht, diese Vereinbarung zu kippen. Für den praktischen Einsatz der beiden Sprachen ist es meistens nicht sinnvoll. Man mag nebenher bemerken, dass diejenigen, die VHDL 'programmieren', fast ausnahmslos erst einmal auf der Nase landen. Das ist ein ganz typisches Problem, auf welches man in der Lehre stößt...
Hamza Oktay schrieb: > habt Ihr paar gängige Programmiersprachen für die parallele > Programmierung parat? Was hast du ungefähr vor? Auf was für einer Hardware soll das laufen? So etwas wie "gängige parallele Programmiersprachen" gibt es an sich nicht. Es gibt Spracherweiterungen für bestimmte Parallelrechner-Architekturen (z.B. CUDA für Nvidia-GPUs), Bibliotheken für die Interprozess(or)-Kommunikation (z.B. MPI) oder Spracherweiterungen zur vereinfachten Parallelisierung (z.B. OpenMP). Was du davon verwendest, hängt von deiner Aufgabe und deinem Rechencluster ab. Eine gute Basis ist sicher, wenn man C kann.
Nase schrieb: > Üblicherweise bezeichnet man VHDL&Co. eher als Beschreibungssprache. > HTML ist auch eine Beschreibungs- und keine Programmiersprache. Das hängt primär davon ab, was für dich eine "Programmiersprache" ist. Letztlich ist jede Programmiersprache eine formale Sprache, mit der man das Verhalten eines Rechnersystems in allgemeiner (Turing-kompletter) Weise definieren kann. Und genau das kann man mit VHDL, nicht aber mit HTML.
P. M. schrieb: > Das hängt primär davon ab, was für dich eine "Programmiersprache" ist. > Letztlich ist jede Programmiersprache eine formale Sprache, mit der man > das Verhalten eines Rechnersystems in allgemeiner (Turing-kompletter) > Weise definieren kann. Und genau das kann man mit VHDL, nicht aber mit > HTML. Genau das habe ich aber oben auch geschrieben. Und ich habe auch geschrieben, dass es gerade bei VHDL sowohl unüblich als auch unpraktisch ist, von einer Programmiersprache zu sprechen.
Nase schrieb: > Und ich habe auch geschrieben, dass es gerade bei VHDL sowohl unüblich > als auch unpraktisch ist, von einer Programmiersprache zu sprechen. Ich habe allerdings geschrieben, dass VHDL eben genau die typischen Eigenschaften einer Programmiersprache hat: Es ist eine formale Sprache, mit der man Turing-komplett Algorithmen beschreiben kann (und zwar ohne Verrenkungen). Nach welchem Paradigma dies geschieht und wie der Algorithmus dann in die Realität umgesetzt wird, spielt doch eigentlich keine Rolle.
Gerade an VHDL und Verilog sieht man doch sehr gut die intrinsische Nebenläufigkeit der Anweisungen. Und wenn man sich dessen nicht bewusst ist, entsteht doch ein Teil der Probleme, nämlich dass viele "reine Softwerker" von der bei den meisten Programmiersprachen vorliegenden sequentiellen Abarbeitung der Befehle ausgehen.
Ich sehe schon, niemand hier kennt die Programmiersprache "Prolog". Die ist weder prozedural oder funktional, sondern deklarativ. Es wird ein Sack voll Fakten und Regel definiert und es Übersetzer und Laufzeitsystem überlassen, wie es anschliessende Fragen auf Basis dieser Fakten und Regeln beantwortet. Die Elemente klassischer Programmiertechnik sucht man darin vergebens, beispielsweise gibt es keine Schleifen. Ein Programm darin definiert im Grundkonzept der Sprache eben keine Anleitung für eine sequentielle (oder parallele) Lösung. Den Kriterien in Beitrag "Re: Parallele Programmiersprachen" folgend wäre das also keine Programmiersprache, sondern eine Beschreibungssprache.
:
Bearbeitet durch User
A. K. schrieb: > Ich sehe schon, niemand hier kennt die Programmiersprache "Prolog". Naja, viele kennen nur die imperative Programmierung, die dadurch gekennzeichnet ist, dass ein Programm eine Nase schrieb: > Sequenz von Befehlen ist. Das Gegenstück zu den imperativen sind die deklarativen Sprachen. Diese teilen sich u.a. auf in die funktionalen (z.B. Haskell), die logischen (z.B. Prolog) und die datenflussorientierten (z.B. Lucid). Da diese Sprachen weniger weit verbreitet sind als C, Java und Basic, sind sie vielen nicht bekannt. Trotzdem gibt es zumindest bei den datenflussorientierten Sprachen zwei, die recht bekannt sind: LabView und Simulink. Da diese aber nicht – wie klassische Programmierprachen – textuell, sondern grafisch sind, werden sie von einigen vielleicht nicht als Programmiersprache akzeptiert. Macht nichts: Es gibt nämlich auch unter den textuellen datenfluss- orientierten Programmierprachen zwei, die ebenfalls recht bekannt sind. Ich verrate jetzt aber nur soviel, dass beide mit V beginnen. Wer meint, die Namen dieser beiden Programmierprachen gefunden zu haben, kann seine Vermutung hier auf Richtigkeit prüfen: http://en.wikipedia.org/wiki/Dataflow_programming#Languages
A. K. schrieb: > Ich sehe schon, niemand hier kennt die Programmiersprache "Prolog". Doch, selbstverständlich kenne ich Prolog und habe gegen Ende der 80er Jahre kurzzeitig mit Turbo Prolog experimentiert. Wie schon richtig beschrieben, ist Prolog eine deklarative Sprache. Sie weist aber keine explizit nebenläufigen Elemente auf.
Andreas Schweigstill schrieb: > Wie schon richtig beschrieben, ist Prolog eine deklarative Sprache. Sie > weist aber keine explizit nebenläufigen Elemente auf. Sequentielle aber auch nicht, zumindest nicht dem Grundprinzip nach. Es wäre wohl schon offen für eine nebenläufige Implementierung. Aber das war als Reaktion auf Nases recht enge Sicht auf Programmiersprachen gedacht, nicht als Empfehlung für parallele Programmierung im Sinn nebenläufiger Prozesse.
:
Bearbeitet durch User
Hallo, um auf die parallele Programmierung zurückzukommen - meiner Meinung nach gibt es eigentlich keine Sprache, die Parallelität ausschliesst. Was soll denn einen Basic-Compiler dran hindern, ein Programm im Rahmen der Optimierung auf unabhängige Abläufe zu untersuchen und diese auf geeigneter Hardware parallel auszuführen? Auf Prozessorebene ist das doch längst Stand der Technik. Nur bei Interpreter-Sprachen dürfte das auf Schwierigkeiten stossen, weil sie nicht weit genug bzw. garnicht vorausschauen können. Man muss wohl unterscheiden zwischen Sprachen oder Spracherweiterungen, in denen man explizit parallel programmieren kann, und solchen, bei denen im Sourcecode garnichts davon drinsteht, die das aber hinter den Kulissen organisieren. Denen dürfte eine grosse Zukunft gehören, weil sich der Programmierer dann nicht drum kümmern muss, und weil sie die gigantischen Mengen vorhandener Software wenigstens teilparallelisieren können. Georg
Georg schrieb: > Nur bei Interpreter-Sprachen dürfte das > auf Schwierigkeiten stossen, weil sie nicht weit genug bzw. garnicht > vorausschauen können. Gegenbeispiel: APL.
A. K. schrieb: > Aber das war als Reaktion auf Nases recht enge Sicht auf > Programmiersprachen gedacht, nicht als Empfehlung für parallele > Programmierung im Sinn nebenläufiger Prozesse. Das sollte auch nicht als enge Sicht herüberkommen. Ich fühle mich bei "VHDL-Programmierung" immer getriggert, dass sich mir die Zehennägel aufrollen. Und zwar aus den oben geschilderten (praxisorientierten) Gründen, aus denen "VHDL-Programmierung" in der Praxis (letztlich: Synthese) eigentlich immer in die Hose geht. Die Bezeichnung "Beschreibungssprache" finde ich aber eigentlich sehr passend, ganz besonders bei nebenläufigen Sprachen. Es drückt eine Abgrenzung zur klassischen Ablaufsteuerung/Sequenz aus: Man programmiert nicht mehr schrittweise einen Ablauf, sondern beschreibt das gewünschte Verhalten. Eigentlich tut man nämlich genau das in VHDL. Und in Prolog.
Nase schrieb: > Die Bezeichnung "Beschreibungssprache" finde ich aber eigentlich sehr > passend, Nur assoziierst du offenbar intuitiv den Begriff "Programmiersprache" mit imperativen Sprachen, während die Informatik darin nur eine Untermenge des von ihr deutlich weiter gefassten Verständnisses von Programmiersprachen sieht. Und da die Informatik in dieser Frage mehr Deutungshoheit hat als deine Zehennägel... > (praxisorientierten) Gründen, aus denen "VHDL-Programmierung" in der > Praxis (letztlich: Synthese) eigentlich immer in die Hose geht. Eine solche Klassifizierung von Sprachen davon abhängig zu machen, ob Anfänger schnell mit ihr klar kommen? Das würde ich ein eher schwaches und insbesondere sehr subjektives Kriterium nennen. Diese Klassifizierung zufolge wäre INTERCAL auch keine Programmiersprache, denn auch da geht ein Versuch, in ihr zu programmieren, eigentlich immer in die Hose. Unabhängig von der Vorbildung. ;-)
:
Bearbeitet durch User
Nase schrieb: > Ich fühle mich bei "VHDL-Programmierung" immer getriggert, dass sich mir > die Zehennägel aufrollen. Meinen Zehennägeln geht es ähnlich, wenn mir ein Web-Designer etwas von "HTML-Programmierung" erzählt (zumindest dann, wenn es dabei um HTML-Versionen von vor HTML5 geht) ;-) > Die Bezeichnung "Beschreibungssprache" finde ich aber eigentlich sehr > passend, ganz besonders bei nebenläufigen Sprachen. Der Begriff ist ja auch vollkommen richtig. Nur denke ich (und viele andere sicher auch) bei "Beschreibungssprache" erst einmal an Sprachen wie Schnittstellenbeschreibungssprachen (z.B. OMG IDL) oder Seiten- beschreibungssprachen (z.B. PCL). Verilog und VHDL sind aber sehr viel mehr: Im Gegensatz zu OMG IDL und PCL erlauben sie nämlich auch die Implementierung komplexer Algorithmen (die auch synthetisierbar sind) und werden dazu auch tatsächlich in großem Umfang genutzt, wie bspw. die inzwischen gängige Umsetzung von Audio- und Videokomprimier- und Bildverarbeitungsverfahren auf FPGAs oder ASICs zeigt. Die Implementierung von Algorithmen wird aber üblicherweise mit dem Begriff "Programmierung" in Verbindung gebracht. Ganz ähnlich verhält es sich mit der Sprache Postscript. Eigentlich ist es – wie auch PCL – eine Seitenbeschreibungssprache für Drucker. Es ist aber gleichzeitig auch eine echte Programmiersprache (ähnlich wie Forth), mit der man bspw. ein Schachprogramm realisieren kann. Den Begriff "Beschreibung" finde ich ganz treffend, solange die Postscript- Datei lediglich dazu dient, Buchstaben und Grafikelemente an fixe Positionen zu platzieren. Sobald aber Konstrukte wie Verzweigungen, Schleifen oder gar Rekursionen verwendet werden, würde ich lieber von "Programmierung" sprechen. Auf Verilog und VHDL übertragen würde dies bedeuten: "Geradeaus-Logik" (die durchaus nicht trivial sein muss) mit ein paar Puffern und etwas Synchronisation mit anderen Komponenten ist für mich "Beschreibung", während ich eine Logik mit vielfach verschachtelten Rückkopplungen, die vielleicht sogar numerische Berechnungen ausführt, durchaus als "Programmierung" ansehen würde. > Es drückt eine Abgrenzung zur klassischen Ablaufsteuerung/Sequenz aus: Wie gesagt, "Programmierung" hat schon lange nicht mehr notwendigerweise etwas mit fest vorgegebenen sequentiellen Abläufen zu tun. Das war nur früher so, als Computer noch größtenteils in Assembler prigrammiert wurden. Das Ganze ist aber sicher einfach nur eine Frage der Sichtweise: Jemand der aus der Algorithmenecke kommt, und in einem FPGA eine hochparallelisierte Rechneinheit sieht, wird dieses "programmieren". Jemand, der jahrelang digitale Schaltungen aus Einzel-ICs entwickelt hat, wird für seine Anwendung eine "Hardwarebeschreibung" anfertigen, früher in Form eines Schaltplans, heute im FPGA-Zeitalter als Verilog/VHDL-Text. Insofern lohnt es sich nicht, hier um Begrifflichkeiten zu streiten :)
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Meinen Zehennägeln geht es ähnlich, wenn mir ein Web-Designer etwas von > "HTML-Programmierung" erzählt ... und oft PHP- oder JavaScript-Programmierung meint. Bei dem was da oft rauskommt können sich zwar auch die Zehennägel aufrollen, aber immerhin stimmt der Begriff der "Programmierung". (Diese Spezies sollte man nur mit UMTS und 10-Zoll Bildschirm auf Atom-V1-Rechnern arbeiten lassen - statt dessen entwicken die lokal auf der Büchse bis es schön aussieht und der Termin überschritten ist, gehen dann quasi ungetestet live und wundern sich, wieso die Kunden fluchen).
:
Bearbeitet durch User
Nunja. Richtig Schwung in die "VHDL-Programmierung" kommt ja jetzt mit der High Level Synthesis u.a. bei Xilinx :-}
Hamza Oktay schrieb: > OpenMP scheint das gängigste zu sein? Was ist zu empfehlen? Es gibt auch noch Posix Threads: http://en.wikipedia.org/wiki/POSIX_Threads und auch Fork: http://en.wikipedia.org/wiki/Fork_%28system_call%29 Ich bevorzuge Posix Threads. Fork ist ganz gut für Fork-Bomben und Zombie-Bomben; gut zum Testen ob die Prozesstabelle richtig limitiert ist. Allerdings sind die für ganz verschiedene Bereiche: OpenMP parallelisiert Programme auf der Ebene von Schleifen, eingesetzt z. B. um Matrizenmultiplikation zu parallelisieren. Bei MPI und Posix Threads werden ganze Prozesse parallel laufen gelassen und die wirken durch Nachrichtenaustausch, z. B. Posix Signale, zusammen. Beim Systemaufruf Fork erzeugt der aktuelle Prozess eine Kopie von sich selbst, welche dann als Kindprozess des erzeugenden Programmes läuft. Also was eingesetzt wird, hängt vom Anwendungsbereich ab.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.