ubuntuusers.de

Hej, mein Laptop hat einen Dual-Core Porzessor, aber die von mir in C geschrieben Programme nutzen immer nur einen; ich compile mit gcc. Wie kann ich beide Prozessoren freigeben?

Danke & Grüße

Frink

Indem Du speziell für Multi Core Systeme programmierst. Für C gibt es z.B. das OpenMP Rahmenwerk.

Man kann auch "händisch" für mehrere Threads programmieren, in der Regel wird das in Linux mittels der Bibliothek/Schnittstelle "PThreads" (Posix Threads) gemacht. Damit kann man mehrere Programmstränge, die parallel laufen können (aber auch können _müssen_, ohne Fehler zu erzeugen) definieren.

Ist im grunde ganz "Simpel" (google mal nach "pthreads"). Die Schwierigkeit ist nur, das Programm so zu planen/durchzuführen, dass die synchronisation stimmt, und z.B. keine Fehler durch "gleichzeitigen" zugriff auf zwischen den Threads geteilte Datenstrukturen entstehen (stichworte lock, mutex, semaphore, ...). Der Linux-Kernel teilt, wenn z.B. 2 Threads gleichzeitig laufen, diese automatisch auf 2 Kerne auf.

Wie gesagt: Entweder eigene Threads oder gleiche eigene Prozesse nutzen. Hat beides Vor- und Nachteile und was man nehmen sollte hängt von der Aufgabenstellung ab. OpenMP würde ich zum Beispiel eher nutzen, wenn es darum geht eine Schleife zu paralellisieren. Wenn ich mehrere unabhängige Aufgaben haben, würde ich eher zu eigenen Prozessen greifen.

Aber ich glaube ehrlich gesagt, dass du dir das falsch vorstellst. Wenn du der Meinung bist, dass du nur einen Schalter beim gcc umlegen musst um eine Multi-Core-Anwendung zu haben, irrst du dich. Bei imperativen Sprachen gibt es sogut wie keinen Weg um völlig automatisiert Multi-Threading zu machen. Funktionale oder logische Sprachen sind da besser geeignet.

Kinch schrieb:

Aber ich glaube ehrlich gesagt, dass du dir das falsch vorstellst. Wenn du der Meinung bist, dass du nur einen Schalter beim gcc umlegen musst um eine Multi-Core-Anwendung zu haben, irrst du dich.

Ja, so habe ich mir das natürlich vorgestellt. Okay, danke für Eure Antworten, ich werde dann mal ein wenig über Posix Threads und OpenMP lesen.

Grüße

Frink

Prof. Frink schrieb:

Kinch schrieb:

Aber ich glaube ehrlich gesagt, dass du dir das falsch vorstellst. Wenn du der Meinung bist, dass du nur einen Schalter beim gcc umlegen musst um eine Multi-Core-Anwendung zu haben, irrst du dich.

Ja, so habe ich mir das natürlich vorgestellt.

☺

Okay, danke für Eure Antworten, ich werde dann mal ein wenig über Posix Threads und OpenMP lesen.

Alternativ könntest Du z.B. auch in Java programmieren; dort ist Unterstützung für MT-Anwendungen bereits in die Sprache und Standard-Bibliothek eingebaut. Etwas näher läge sicherlich auf C++ umzusteigen, aber ich weiß nicht, wie weit der gcc schon die neuen MT-Features unterstützt.

Ciao

robert

rklm schrieb:

Alternativ könntest Du z.B. auch in Java programmieren

Okay, danke für den Hinweis; aber ich habe jetzt gerade erst C gelernt und bleibe erstmal dabei; Java gucke ich mir bestimmt auch irgendwann noch mal an.

"Starte dein Programm doch einfach zweimal, dann nutzt es auch beide Kerne aus..." 😉

In dem Artikel um die MT-features geht es ja auch nicht um höhere Magie, sondern einfach um eine portable Schnittstelle in Sachen Threads, die, soweit ich sehe, auch nur das Gleiche macht wie pthreads. Pthreads + C ist schon in Ordnung, in sachen Portabilität: es gibt auch pthreads-"wrapper" die unter windows die gleiche funktionalität wie auf posix-systemen bereitstellt. Der Funktionsumfang für sowas ist halt eher gering, damit richtig zu arbeiten aber eine Kunst für sich.

Als erstes musst du immer sehen, ob dein Programm, bzw. die zu Erledigenden Aufgaben, überhaupt geeignet zum Parallelisieren (ausnutzen mehrerer Kerne gleichzeitig) ist.

Nicht geeignet ist z.B. eine Schleife, wo jeder Durchgang vom Ergebnis des vorherigen Durchgangs abhängig ist, und wo man die Berechnung nicht in mehrere Schritte teilen kann.

Gut geeignet sind voneinander grösstenteils unabhängige Mechanismen (z.B. Spiele: ein thread Grafik, ein thread sound, beides läuft "gleichzeitig", und wird von einem Hauptthread, der die Logik des Spieles unterhält zwischendurch durch Signale mit geringer Frequenz & geringem Datenvolumen gesteuert).

Gut geeignet sind auch Berechnungen aufgrund von Vorhandenen Startwerten (kann auch der Schleifeniterator sein), die im Ergebnis nich voneinander abhängen, und oft wiederholt werden. Hier Teilt man die Arbeit, z.B. in Pakete mit Grundwerten, und lässt Threads dann die Pakete abarbeiten. Wichtig ist, dass es gleichzeitig gehen muss.

Auch geeignet sind Probleme, die in mehrere Schritte geteilt werden können. z.B. ein Thread, der Schritt 1 der berechnung xmal ausführt, und die Ergebnisse, die für Schritt 2 benötigt werden in ein Paket Schreibt. Ist ein Paket fertig, lässt man einen zweiten Thread das Paket zuendeberechnen, während der erste schon das nächste vorbereitet. Normalerweise heisst es, man solle Aufgaben in einer Schleife möglichst in einem Durchgang abarbeiten, aber da beide Schritte nun "gleichzeitig" laufen können, erhält man geschwindigkeitszuwachs.

Hirnbiegend sind halt noch die Synchronisation der Threads (z.B. mit einem Mutex Datenstrukturen vor "Kreuzfeuer" Schützen, die in mehreren Threads geschrieben/gelesen werden), und die verwendeten Funktionen "Thread-Safe" zu gestalten. Nutzt eine Funktion z.B. statischen Speicher, der immer der Gleiche ist, kann es problematisch werden, wenn die Funktion durch Zufall oder System grade 2 mal parallel läuft, und die beiden Instanzen sich gegenseitig den Speicher zerphuckeln. Sowas muss man halt schlau entwerfen, sonst gibt's böse überraschungen, und Fehler die SAUSCHWER zu finden sind, weil sie im Zweifel auch nur sehr selten auftreten.

Eigenständige Prozesse sind auch ein Weg, aber nur wenn die geteilten Daten wenige sind, und die einzelnen Prozesse aus sicherheitsgründen den Kompletten Speicher der anderen Fäden nicht sehen können dürfen, oder generell mit verschiedenen Rechten laufen sollen. Threads sind wie ein Programm, das mit mehreren Funktionen (meist in Schleifen) gleichzeitig Läuft, und den ganzen Speicher, Rechte, Dateideskriptoren usw. Teilt. Prozesse sind dann schon eher eigenständige Programme für sich - die man natürlich auch Synchronisieren kann, um das gleiche wie mit Threads zu bewerkstelligen.

Hej, danke für die ausführliche Erklärung.

TraumFlug schrieb:

"Starte dein Programm doch einfach zweimal, dann nutzt es auch beide Kerne aus..." 😉

Ja, man kann natürlich, wenn man eine aufwendige Berechnung für zwei Startwerte ausführen will, dasselbe Programm mehrmals mit unterschiedlichen Parametern starten, aber das ist dann wohl; C auf Multi-Core-Systemen für ganz Arme.

TraumFlug schrieb:

Als erstes musst du immer sehen, ob dein Programm, bzw. die zu Erledigenden Aufgaben, überhaupt geeignet zum Parallelisieren (ausnutzen mehrerer Kerne gleichzeitig) ist.

Tatsächlich eigenen sich die von mir bisher geschrieben Programme wohl eher nicht dafür; außerdem war der Rechenaufwand bisher auch meistens so gering, dass es nicht so auf die Geschwindigkeitsoptimierung ankommt.

TraumFlug schrieb:

Auch geeignet sind Probleme, die in mehrere Schritte geteilt werden können. z.B. ein Thread, der Schritt 1 der berechnung xmal ausführt, und die Ergebnisse, die für Schritt 2 benötigt werden in ein Paket Schreibt. Ist ein Paket fertig, lässt man einen zweiten Thread das Paket zuendeberechnen, während der erste schon das nächste vorbereitet. Normalerweise heisst es, man solle Aufgaben in einer Schleife möglichst in einem Durchgang abarbeiten, aber da beide Schritte nun "gleichzeitig" laufen können, erhält man geschwindigkeitszuwachs.

Das klingt für mich noch am interessantesten.

Ich werde mir mal ein paar einfache Beispiele zu Gemüte führen, damit ich dann eine ungefähre Ahnung habe, wenn ich es mal wirklich brauche.

Danke!