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.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sma hat geschrieben:Übrigens, Leonidas, hast du einen Hinweis auf Green-Threads in Clojure?
Ok, wie ich nach einigem Suchen herausgefunden habe, meinte ich da Scala (was du auch schon angesprochen hast), sorry, mein Fehler. In Clojure läuft das nur über Threads. Allerdings sind Java Threads laut den Kommentaren auch nicht so das wahre. Immerhin habe ich noch eine interessante Concurrency-Debatte in einem anderen Blog gefunden, wo das auch noch etwas aufgerollt wird.

Du siehst ja selbst, dass Google auf Multiprozesse gegangen ist, die ebenfalls parallel laufen. Speicher zwischen Applikationen zu teilen ist auch kein neues Konzept. Aber deine Szenarios gehen eher auf wirklich große Anwendungsgebiete ein. Solcherlei Anwendungen wird es zwar in Zukunft mehr geben, aber nicht in dem Ausmaß. Das sind eben Sachen die auf großen und dicken Rechnern laufen die von einer Horde von Admins gepflegt haben und schon heutzutage mehr als 64 Kerne bieten (eigentlich sinds wohl eher Cluster).

Und ja, Stackless hat einen GIL (interessanterweise kursieren im Internet auch Behauptungen dass dies nicht der Fall sei). Aber es war auch die rede von einer "stackless" VM und keiner GIL-less VM.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Hier wird jetzt irgendwie munter Threads und Prozesse gemischt. Threads gehören für mich zusammen auf einen Prozessor (Kern) und so wie ich das verstehe wäre es ja auch kein Problem davon mal 1000 Stück zu starten (ob das sinnvoll ist steht auf einem anderen Blatt).

Zumindest wäre das nach meinem Verständnis nach so zu verstehen. Ansonsten sähe ich keinen Sinn in der Trennung zwischen Thread und Prozess.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

burli hat geschrieben:[...]und so wie ich das verstehe wäre es ja auch kein Problem davon mal 1000 Stück zu starten (ob das sinnvoll ist steht auf einem anderen Blatt).
Ob du dass so siehst oder nicht interessiert die harte Realität aber nicht, da gehts nämlich nicht unbedingt.
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

DasIch hat geschrieben: Ob du dass so siehst oder nicht interessiert die harte Realität aber nicht, da gehts nämlich nicht unbedingt.
Und warum nicht?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

burli hat geschrieben:
DasIch hat geschrieben: Ob du dass so siehst oder nicht interessiert die harte Realität aber nicht, da gehts nämlich nicht unbedingt.
Und warum nicht?
Kann verschiedene Gründe haben, etwa dass du so viel Speicher gar nicht hast, der OS-Scheduler so ineffizient ist oder weil der Interpreter einen GIL hat.

Und das Prozesse auf einem Prozessor laufen stimmt so auch nicht. Im Thread werden sogar noch mehr Dinge gemischt: Green-Threads (Tasklets in Stackless, Prozesse in Erlang, Event-Basierte Actors in Scala), OS-Threads (die Threads die die JVM unterstützt oder der Python-Interpreter) und OS-Prozesse (jede VM ob nun Java, Python oder Erlang haben belegen einen Prozess).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
Antworten