Hallo, gibt es eine möglichkeit, mehrere CPUs unter C (und Linux ;-)) zu verwenden, um 2 Prozesse parallel laufen zu lassen? LG Matthias
Gast
#2858153
der wohl schnellste und einfachste weg wäre der systemaufruf fork()
Gast
#2858181
Matthias R. schrieb: > gibt es eine möglichkeit, mehrere CPUs unter C (und Linux ;-)) zu > verwenden, um 2 Prozesse parallel laufen zu lassen? ja (z.b mit threats)
Gast
#2858251
Matthias R. schrieb: > Hallo, > gibt es eine möglichkeit, mehrere CPUs unter C (und Linux ;-)) zu > verwenden, um 2 Prozesse parallel laufen zu lassen? Dazu brauchst du gar nichts zu tun. Das System verteilt die Prozesse automatisch auf die CPUs. Es gibt aber auch Möglichkeiten, Prozesse explizit einzelnen CPUs bzw. Kernen zuzuordnen.
> z.b mit threats Ich bekomme Angst ;) Unter Unixoiden in plain-C sind pthreads das Mittel der Wahl für allgemeine Parallelisierung: https://computing.llnl.gov/tutorials/pthreads/ In C++ kann man pthreads auch nutzen, muss aber mit Wrappern arbeiten, damit man wieder ein this-Pointer bekommt. Da kann man dann gleich die Threads aus einem Toolkit nehmen (Qt, ...). Wenn es in Richtung High-Performance-Computing zur Parallelisierung von Algorithmen geht: OpenMP http://openmp.org/wp/ Kann der gcc auch schon: http://gcc.gnu.org/wiki/openmp Dazu gibt man im Code selbst per pragmas Hinweise auf parallel ausführbare Teile (for-Schleifen, etc.).
an der uni haben wir mal in einer vorlesung mpi und openmp miteinander kombiniert. das macht spaß - und wenn man nicht aufpasst hat man sehr schnell einen knoten im hirn ;-) kommt darauf an was du machen willst. für eine shared-memory-maschine würde ich openmp empfehlen, ist recht einfach zu handlen. wenns hauptsächlich um den lerneffekt geht: selber machen (threads, signals, shared memory, semaphoren, ...)
Georg A. schrieb: > Unter Unixoiden in plain-C sind pthreads das Mittel der Wahl für > allgemeine Parallelisierung Die ernstgemeinten Windows-Versionen bieten seit 1993 ihre eigene Variante von Threads an und sind seitdem auch in der Lage, diese automatisch auf mehrere Kerne bzw. mehrere CPUs zu verteilen. Threads werden entweder mit der Win32-API-Funktion CreateThread oder (je nach Compiler und Runtime-Unterstützung) mit _beginthread resp. _beginthreadex erzeugt. Wenn hingegen tatsächlich Prozesse im Sinne eigenständiger Programme gemeint ist, dann heißt die zu verwendende Win32-API-Funktion CreateProcess. Mit den Win32-API-Funktionen SetProcessAffinityMask und SetThreadAffinityMask lässt sich die Verteilung von Prozessen und Threads auf einzelne Kerne/Prozessoren beeinflussen.
Danke für die hilfreichen Antworten! Was ist das schnellste von diesen Verfahren? Ich bin momentan ein Programm am schreiben das wie folgend aufgebaut ist: Hauptprogramm Nebenprogramm, das auf neue Daten wartet
Matthias R. schrieb: > Was ist das schnellste von diesen Verfahren? > [...] Nebenprogramm, das auf neue Daten wartet Du willst besonders schnell warten? Nach dem Motto: Wir warten noch schnell auf Weihnachten...
> Was ist das schnellste von diesen Verfahren?
Schnell im Sinne von schnell zu schreiben: pthreads
Allerdings solltest du dich auch mit den Synchronisationsmechanismen
zwischen den Threads auseinandersetzen. Irgendwie müssen die Daten ja
die Threads wechseln... Da gibt es viele Stolperfallen, wenn man es das
erste Mal macht. Die pthreads haben dazu auch ein paar hilfreiche Calls.
Georg A. schrieb: > Schnell im Sinne von schnell zu schreiben: pthreads genau das mein ich ;) Danke!!
http://cs.gmu.edu/~white/CS571/Examples/pthread_examples.html Und immer schon mit -lpthread linken, sonst gibts unbekannte Symbole...
Für die Kommunikation zwischen den Threads bieten sich Pipes an.
> Für die Kommunikation zwischen den Threads bieten sich Pipes an.
Hängt von der Art der notwendigen Kommunikation ab. Nicht alles lässt
sich gut auf ein so Stream-Modell übertragen. Das kann in ein ziemliches
Kommandorumgeschiebe ausarten, dann gibts noch das Problem von Blocking
und potentieller De-Synchronisation.
Pipes sind auch nicht besonders effizient, weil sie trotz selbem
Adressraum durch den Kernel gehen. Bei grösseren Datenmengen ist es
deutlich effizienter, das FIFO selber zu schreiben. Solange ein(1)
Prozess nur schreibt und einer(1) nur liest, kommt man auch ohne
Semaphore&Co aus.
Georg A. schrieb: > Solange ein(1) > Prozess nur schreibt und einer(1) nur liest, kommt man auch ohne > Semaphore&Co aus. Interessante Hypothese! Cache-Kohärenz?
Konrad S. schrieb: > Interessante Hypothese! Cache-Kohärenz? Ist das gleiche Verfahren, mit dem man auch Puffer von UARTs im Interrupt-Betrieb betreiben kann, ohne im Hauptprogramm die Interrupts abschalten zu müssen. Voraussetzung dafür ist, dass Cache-Kohärenz gewährleistet ist, Lese- und Schreiboperationen der Indizes atomar sind und das memory ordering model gewissen Ansprüchen genügt. Ein meist harmloser Nebeneffekt ist, dass ein N Bytes grosser Puffer nur maximal N-1 Bytes aufnehmen kann. Bei PC-Systemen sind diese Vorbedingungen gewährleistet. Allerdings kann die Kohärenz auf die Performance drücken, wenn auf die Indizes in sehr kurzen Abständen durch verschiedene Cores zugegriffen wird. Das kann Thrashing zur Folge haben, d.h. Cache-Lines wandern in schneller Folge zwischen den Caches der Cores hin und her. Das ist nicht ganz billig. Hat man es also mit hohen Datenraten zu tun, bei denen dieser Effekt relevant wird, dann können andere Verfahren sinnvoller sein.
Sind ja 'ne ganze Menge Nebenbedingungen. Dann lieber mit Pthreads, Mutexes und Condition-Variablen und es funktioniert auch auf 'nem großen Hobel ohne Probleme.
Konrad S. schrieb: > Sind ja 'ne ganze Menge Nebenbedingungen. Geht so. Wer in der Doku von 32-Bit Cores wie den Cortex-M schon mal über das Thema memory ordering models stolperte, der weiss jetzt wenigstens an welcher Stelle so etwas relevant ist. ;-) > Mutexes und Condition-Variablen und es funktioniert auch auf 'nem großen > Hobel ohne Probleme. So arg viele deutlich grössere shared memory Hobel als PCs und PC-Server gibts andererseits nicht mehr. Bei den wirklich grossen Clustern mit hunderten von Prozessoren (oder mehr) funktioniert die Kommunikation ohnehin nicht mehr über shared memory. Und dann muss man das betreffende System genau kennen und sich im Vorfeld klare Gedanken über das Zeitverhalten der Kommunikation machen, sonst kann es passieren, dass die daneben stehende PC-Workstation schneller fertig ist.
A. K. schrieb: > So arg viele deutlich grössere shared memory Hobel als PCs und PC-Server > gibts andererseits nicht mehr. Leider!
Gast
#2861645
Georg A. schrieb: > http://cs.gmu.edu/~white/CS571/Examples/pthread_ex... > > Und immer schon mit -lpthread linken, sonst gibts unbekannte Symbole... Eigentlich sollte mit -pthread gelinkt und am besten auch compiliert werden.
> Eigentlich sollte mit -pthread gelinkt und am besten auch compiliert > werden. Wenn man auf einem PowerPC unterwegs ist, möglicherweise, sonst scheint die Option keiner mehr zu brauchen...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.