Multi-Core Prozessing

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

burli hat geschrieben:Und warum nicht?
Siehe smas ersten Post. 1 MB Speicher pro Thread macht bei 1000 Threads einen GB.
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Mag sein das 1000 Threads in Python nicht möglich sind.

Vielleicht hab ich ja auch ein anderes Verständnis von Threads und Prozessen. Für mich sind Prozesse eigenständig laufende Einheiten und Threads sehe ich im Wesentlichen als Untereinheit von Prozessen.

Vom Prinzip her sind sich beide ähnlich.

@DasIch: Für mich klang das nach einer hypothetischen Annahme, nicht nach einem Fakt. 1MB pro Thread ist definitiv zu hoch gegriffen
BlackJack

@burli: Threads sind nicht an einen Prozessor(kern) gebunden, sondern nur an einen Prozess. Ist jedenfalls bei Linux' POSIX-Threads so.

Und ich habe gerade mal nachgeschaut: Bei mir auf dem System (32-Bit) ist die voreingestellte Stapelgrösse pro Thread 8 MiB. Also deutlich mehr als 1 MiB. 1000 Threads könnte ich also ganz bestimmt nicht starten. Das sprengt nicht nur meinen Arbeitsspeicher, sondern auch den Adressraum eines Prozesses.

Und Python startet solche Systemthreads.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

BlackJack hat geschrieben:Letztlich bringt dieses rumlamentieren über das böse GIL nichts, solange nicht jemand eine neue Python-Implementierung schreibt, die ohne auskommt. Anpassen der aktuellen CPython-Implementierung geht nicht -- das wurde ja schon probiert und das Ergebnis war, das man dann soviel "lock"en muss, dass der Interpreter signifikant langsamer wäre.
Vielleicht bring PyPy da in Zukunft Abhilfe?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Vielleicht, aber so wie ich einige Beiträge in der englischsprachigen Newsgroup verstanden habe, ist das Ziel von PyPy gar nicht mal unbedingt einen Ersatz für CPython zu haben, sondern eher ein Forschungsprojekt. Das Ziel wäre also auch erreicht, wenn "nur" viele schöne Paper dabei heraus kommen und eine "proof of concept"-Implementierung.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Ich habe erst letztens von irgendwem gelesen, der CPython GIL-frei machen wollte, mit irgendeinem neuen Ansatz. Aber ich weiß nicht was daraus geworden ist/wird, vielleicht weiß jemand anderes da mehr...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Qubit
User
Beiträge: 128
Registriert: Dienstag 7. Oktober 2008, 09:07

Leonidas hat geschrieben:Ich habe erst letztens von irgendwem gelesen, der CPython GIL-frei machen wollte, mit irgendeinem neuen Ansatz. Aber ich weiß nicht was daraus geworden ist/wird, vielleicht weiß jemand anderes da mehr...
Meinst du Adam Olsen?
http://code.google.com/p/python-safethr ... loads/list
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Qubit hat geschrieben:Meinst du Adam Olsen?
Oh, ja, genau das war es. Andererseits wird er mit "However, the base (single-threaded) throughput is only around 60-65% that of normal CPython" wohl eher kaum demnächst sonderlich populär werden.

Wird auch im Python Concurrency Lighning Talk angesporochen und mit anderen Ansätzen verglichen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

1MB Patch. Beeindruckend. Gibt es irgendwo eine genauere Erklärung, warum die Performance so einbricht? Die wesentliche geteilte Ressource ist doch der Programmcode sowie globals und builtins. Veränderbare dicts zu benutzen, wo man jetzt jeden lesenden (und schreibenden) Zugriff absichern muss, könnte der Grund sein.

Mein Versuch wäre, die Semantik von Python zu ändern. Zugriffe mit globals() und locals() sind zwar manchmal praktisch, aber wenn man diese Interna nicht aufdeckt, kann man andere Datenstrukturen benutzen und so z.B. pro Thread verwalten und direkt darauf zugreifen. Sollte man vielleicht sogar die module-dicts pro thread anlegen und nur die unveränderlichen function- und code-Objekte teilen?

Stefan
lunar

sma hat geschrieben:Sollte man vielleicht sogar die module-dicts pro thread anlegen und nur die unveränderlichen function- und code-Objekte teilen?
Und wie sollten Threads dann miteinander kommunizieren? Das setzt ja zumindest irgendein thread-übergreifendes Objekt voraus, wenn aber bereits die Namensräume selbst threadlokal sind, kann man ein solches Objekt gar nicht erzeugen.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Man könnte das Prinzip von Erlang benutzen, wo sich prozesse asynchron Nachrichten schicken können. Alles was man dazu braucht, ist ein Process Handle und den bekommt der Vater, wenn er das Kind erzeugt. Jeder Prozess kennt außerdem sein eigenes Handle.

In Python z.B.

Code: Alles auswählen

child_pid = spawn(child_function)
send(child_pid, "hello from father", pid())
Zum Empfangen von Nachrichten sollte es dann aber noch ein neues Schlüsselwort geben, wenn das genauso wie bei Erlang funktionieren soll.

Eine andere Möglichkeit wäre, einem Thread bei der Erzeugung die zu teilenden Objekte explizit mitzugeben. Da wüsste man dann auch, dass dies threadsafe-Varianten von veränderbaren Datenstrukturen (sharedlist, shareddict, usw.) sein müssten.

Stefan
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

So, ich hab das Thema nochmal ausgegraben weil es mich doch interessiert. Eine einfache Möglichkeit, verschiedene Prozesse auf mehrere Cores zu verteilen ist eigentlich banal. Man startet einfach die Prozesse mit Subprocess.

Ja, ich weiß. das ist die Brechstangenmethode, die ihre eigenen Probleme aufwirft, aber ein erster Versuch ist vielversprechend. Ich hab das Mandelbrot Programm aus einem anderen Thread mal auf einem Atom330 (Dual Core mit Hyper Threading) ausgeführt. Einzeln brauch das Programm (mit psyco) 22 Sekunden. Startet man zwei gleichzeitig ändert sich daran nicht viel. Startet man vier brauchen sie jedoch fast 40 Sekunden.

Die Kommunikation könnte man über einen TCP/IP Stack, XML-RPC oder ähnliches realisieren.

Nur um das klar zu stellen: es geht mir im Moment nicht um echte parallele Programmierung sondern um die Ausnutzung der vorhandenen Ressourcen in bestimmten Anwendungsfällen. Mit der Methode kann man nicht alle Probleme lösen. Aber man kann rechenintensivere Aufgaben auf mehrere Prozessoren bzw Kerne verteilen.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

@burli Die Kommunikation ist viel zu umständlich außerdem ist XMLRPC dumm.
lunar

burli hat geschrieben:Ja, ich weiß. das ist die Brechstangenmethode, die ihre eigenen Probleme aufwirft, aber ein erster Versuch ist vielversprechend. Ich hab das Mandelbrot Programm aus einem anderen Thread mal auf einem Atom330 (Dual Core mit Hyper Threading) ausgeführt. Einzeln brauch das Programm (mit psyco) 22 Sekunden. Startet man zwei gleichzeitig ändert sich daran nicht viel. Startet man vier brauchen sie jedoch fast 40 Sekunden.
Das einzige, was du damit "bewiesen" hast, ist die Tatsache, dass der Scheduler des Betriebssystems Prozesse auf verfügbare Prozessoren verteilt. Weder ist das besonders atemberaubend, noch hat das einen näheren Bezug zu Python.
Die Kommunikation könnte man über einen TCP/IP Stack, XML-RPC oder ähnliches realisieren.
Das wiederum hätte Bezug zu Python, wird aber nur mit Allgemeinplätzen abgedeckt. Das man TCP/IP für IPC nutzen kann, weiß jeder, interessant ist nur, wie man das vernünftig umsetzt. XMLRPC ist übrigens ein ziemlich ungeeignetes Format für IPC bei rechenintensiven Prozessen, weil es sehr viel Overhead erzeugt.
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Warum umständlich?

@Lunar: das ist mir schon klar. Es hat mit Python nicht direkt was zu tun. Mich hat einfach interessiert, wie es geht und vor allem wie gut.

Das XML-RPC nicht das geeignetste Format ist denke ich mir. Mit dem Teil habe ich mich noch nicht befasst und war nur eine Möglichkeit um die Idee zu demonstrieren
Flano
User
Beiträge: 43
Registriert: Sonntag 5. September 2004, 14:13

Was ist eigentlich von "Parallel Python" zu halten. Ist das echtes Multicore Prozessing?

http://www.parallelpython.com/

Gruss Flano
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Flano hat geschrieben:Was ist eigentlich von "Parallel Python" zu halten. Ist das echtes Multicore Prozessing?
Steht doch da
PP is a python module which provides mechanism for parallel execution of python code on SMP (systems with multiple processors or cores) and clusters (computers connected via network)
Ich kann mir vorstellen, das die im Wesentlichen das gleiche machen wie ich in meinem Versuch, nur das sie ein paar Kommunikations- und Steuerfunktionen eingebaut haben.
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Hoi,

kennt ihr PYRO?

Das ist vielleicht eine praktische Lösung für diese eher theoretische Diskussion. Zumindest mit einem Linux-Cluster habe ich da schon Gutes gehört - aber selber noch nicht ausprobiert.

Gruß,
Christian

PS Ich weiß, dass das hier Gesagte damit nicht ungültig wird - im Gegenteil. Muß man mich jetzt nicht drauf hinweisen ;-).
Antworten