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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 24. November 2008, 15:58

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 Modvoice
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Montag 24. November 2008, 16:07

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: 2462
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Montag 24. November 2008, 16:09

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: 1116
Registriert: Dienstag 9. März 2004, 18:22

Montag 24. November 2008, 16:11

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 24. November 2008, 16:28

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 Modvoice
DasIch
User
Beiträge: 2462
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Montag 24. November 2008, 16:35

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: 1116
Registriert: Dienstag 9. März 2004, 18:22

Montag 24. November 2008, 16:39

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

Montag 24. November 2008, 17:31

@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
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 24. November 2008, 17:45

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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Montag 24. November 2008, 18:06

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 24. November 2008, 20:20

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 Modvoice
Qubit
User
Beiträge: 75
Registriert: Dienstag 7. Oktober 2008, 09:07

Montag 24. November 2008, 20:48

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 24. November 2008, 21:04

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 Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Dienstag 25. November 2008, 09:48

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

Dienstag 25. November 2008, 10:13

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.
Antworten