Siehe smas ersten Post. 1 MB Speicher pro Thread macht bei 1000 Threads einen GB.burli hat geschrieben:Und warum nicht?
Multi-Core Prozessing
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
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
@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.
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.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Vielleicht bring PyPy da in Zukunft Abhilfe?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, 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.
-
- 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
Meinst du Adam Olsen?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...
http://code.google.com/p/python-safethr ... loads/list
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Qubit hat geschrieben:Meinst du Adam Olsen?
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
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
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
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 hat geschrieben:Sollte man vielleicht sogar die module-dicts pro thread anlegen und nur die unveränderlichen function- und code-Objekte teilen?
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.
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
In Python z.B.
Code: Alles auswählen
child_pid = spawn(child_function)
send(child_pid, "hello from father", pid())
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
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.
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.
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.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 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.Die Kommunikation könnte man über einen TCP/IP Stack, XML-RPC oder ähnliches realisieren.
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
@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
Was ist eigentlich von "Parallel Python" zu halten. Ist das echtes Multicore Prozessing?
http://www.parallelpython.com/
Gruss Flano
http://www.parallelpython.com/
Gruss Flano
Steht doch daFlano hat geschrieben:Was ist eigentlich von "Parallel Python" zu halten. Ist das echtes Multicore Prozessing?
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.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)
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 .
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 .