Pthreads vs. OpenMP

Ich erstelle eine Multithread-Anwendung in C mit Linux.

Ich bin mir nicht sicher, ob ich die POSIX-Thread-API oder die OpenMP-API verwenden soll.

Was sind die Vor- und Nachteile der Verwendung von beiden?

Bearbeiten:

Könnte mal jemand klären ob beide APIs schaffen Kernel-Ebene oder Benutzerlevel Fäden?

Pthreads und OpenMP repräsentieren zwei völlig unterschiedliche Multiprocessing-Paradigmen.

Pthreads ist eine API auf sehr niedriger Ebene für die Arbeit mit Threads. Somit haben Sie eine äußerst feinkörnige Kontrolle über das Thread-Management (erstellen/beitreten/usw.), Mutexe und so weiter. Es ist ziemlich nackte Knochen.

Auf der anderen Seite, OpenMP ist viel höher, ist portabler und beschränkt Sie nicht auf die Verwendung von C. Es ist auch viel einfacher zu skalieren als pthreads. Ein konkretes Beispiel dafür sind die Arbeitsteilungskonstrukte von OpenMP, mit denen Sie die Arbeit relativ einfach auf mehrere Threads aufteilen können. (Siehe auch Wikipedia Pro- und Contra-Liste.)

Allerdings haben Sie wirklich keine Details über das spezifische Programm angegeben, das Sie implementieren, oder wie Sie es verwenden möchten, sodass es ziemlich unmöglich ist, eine API der anderen vorzuziehen.

Wenn Sie OpenMP verwenden, ist es kann so einfach wie das Hinzufügen eines einzigen Pragmas sein, und Sie haben 90 % des Weges zu ordnungsgemäßem Multithreading-Code mit linearer Beschleunigung. Um den gleichen Leistungsschub mit pthreads zu erzielen, ist viel mehr Arbeit erforderlich.

Aber wie üblich erhalten Sie mit pthreads mehr Flexibilität.

Grundsätzlich kommt es darauf an, was Ihre Anwendung ist. Haben Sie einen trivial parallelisierbaren Algorithmus? Oder haben Sie einfach viele beliebige Aufgaben, die Sie gleichzeitig erledigen möchten? Wie viel brauchen die Aufgaben, um miteinander zu sprechen? Wie viel Synchronisation ist erforderlich?

OpenMP hat den Vorteil, dass es plattformübergreifend und für einige Operationen einfacher ist. Es handhabt das Threading auf eine andere Weise, indem es Ihnen Threading-Optionen auf höherer Ebene bietet, wie z. B. die Parallelisierung von Schleifen, wie z.

#pragma omp parallel for
for (i = 0; i < 500; i++)
    arr[i] = 2 * i;

Wenn Sie das interessiert und C++ eine Option ist, würde ich es auch empfehlen Threading-Bausteine.

Pthreads ist eine API auf niedrigerer Ebene zum expliziten Generieren von Threads und Synchronisieren. Insofern bietet es mehr Kontrolle.

Es hängt von 2 Dingen ab – Ihrer Codebasis und Ihrem Platz darin. Die Schlüsselfragen lauten: 1) „Verfügt Ihre Codebasis über Threads, Threadpools und die Steuerungselemente (Sperren, Ereignisse usw.)“ und 2) „Entwickeln Sie wiederverwendbare Bibliotheken oder gewöhnliche Apps?“

Wenn Ihre Bibliothek über Thread-Tools verfügt (die fast immer auf einer Art PThread basieren), VERWENDEN SIE DIESE. Wenn Sie Bibliotheksentwickler sind, verbringen Sie die Zeit (wenn möglich) damit, sie zu erstellen. Es lohnt sich – Sie können viel feinkörnigeres, fortschrittlicheres Threading zusammenstellen, als OpenMP Ihnen bieten wird.

Umgekehrt, wenn Sie unter Zeitdruck stehen oder nur Apps oder etwas mit Tools von Drittanbietern entwickeln, verwenden Sie OpenMP. Sie können es in ein paar Makros packen und erhalten die grundlegende Parallelität, die Sie benötigen.

Im Allgemeinen ist OpenMP gut genug für einfaches Multithreading. Sobald Sie an den Punkt kommen, an dem Sie Systemressourcen verwalten, die direkt auf die Erstellung von hoch asynchronem Code ausgerichtet sind, wird der Vorteil der Benutzerfreundlichkeit durch Leistungs- und Schnittstellenprobleme verdrängt.

Denk darüber so. Auf einem Linux-System ist es sehr wahrscheinlich, dass die OpenMP-API selbst verwendet wird pthreads um seine Funktionen wie Parallelität, Barrieren und Sperren/Mutex zu implementieren. Allerdings gibt es gute Gründe, direkt mit der pthreads-API zu arbeiten.

Es ist meine Meinung, dass –

Sie verwenden OpenMP, wenn –

• Ihr Programm enthält leicht zu erkennen for Schleifen, bei denen jede Iteration unabhängig von anderen ist.
• Sie möchten die Lesbarkeit des Programms erhalten. (Das parallelisierte Programm sollte grundsätzlich wie die sequentielle Version aussehen)
• Sie möchten sich von den wesentlichen Details fernhalten, wie Threads auf Mikroebene erzeugt und gesteuert werden.

Und pthreads wenn –

• Schleifen lassen sich nicht einfach parallelisieren.

• Sie haben verschiedene Aufgaben, die gleichzeitig ausgeführt werden müssen, und Sie möchten möglicherweise jeder dieser Aufgaben unterschiedliche Verantwortlichkeiten zuweisen.

• Sie möchten den Ablauf der Thread-Ausführung auf Mikroebene steuern.

Fühlen Sie sich frei, mich in den Kommentaren zu korrigieren.