Modul: multitask braucht man das?

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Kann ich trozdem auch weiterhin bei den Pythonmitgeliferten Threading Varianten bleiben oder was bringt das Modul mehr?

http://o2s.csail.mit.edu/o2s-wiki/multitask
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Es erinnert mich von der Einfachheit der Nutzung an die Ruby-Threads, die ja auch Soft-Threads sind. Es hat eine nette API. Letztendlich hast du damit Gleichzeitigkeit, ohne Threads zu nutzen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

Leonidas hat geschrieben:Es erinnert mich von der Einfachheit der Nutzung an die Ruby-Threads, die ja auch Soft-Threads sind. Es hat eine nette API. Letztendlich hast du damit Gleichzeitigkeit, ohne Threads zu nutzen.
Gibt es da irgendeinen essentiellen, wichtigen Vorteil?
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

lunar hat geschrieben:
Leonidas hat geschrieben:Es erinnert mich von der Einfachheit der Nutzung an die Ruby-Threads, die ja auch Soft-Threads sind. Es hat eine nette API. Letztendlich hast du damit Gleichzeitigkeit, ohne Threads zu nutzen.
Gibt es da irgendeinen essentiellen, wichtigen Vorteil?
Weniger Problem mit der Nebenläufigkeit was zu geringerer Komplexität, weniger Bugs und vereinfachtem Debugen führt. Ich muss zwar zugeben dass ich noch nie eine Python Awendung mit mehreren Threads debugt habe aber ich denke es wird ähnlich mühsam sein wie in anderen Sprachen. Abgesehen davon ist es in einigen Fällen sogar schneller als echte Threads da der aufwand einen Thread zu erstellen relativ gross ist (Ja, kann mit Pooling gesenkt werden).
BlackJack

Ich kenne diese Implementierung jetzt nicht, aber meistens wird bei Coroutinen angeführt, dass der Overhead geringer ist als bei Threads. Sie laufen komplett im Userspace, es gibt also kein "(kleines) Taskswitching", und man kann im allgemeinen beliebig viele davon starten. Wenn man zum Beispiel eine Ameisenkolonie mit 3000 Computerspielern simulieren will, dann sollte man besser keine 3000 Threads starten. ;-) Falls das Betriebssystem das überhaupt mitmacht.
lunar

veers hat geschrieben:Abgesehen davon ist es in einigen Fällen sogar schneller als echte Threads da der aufwand einen Thread zu erstellen relativ gross ist (Ja, kann mit Pooling gesenkt werden).
Ich habe keine Ahnung von Windows, allerdings glaube ich nicht, dass der Aufwand zum Erzeugen von Threads unter Linux sehr, sehr groß ist. Immerhin erzeugt fork() unter Unix sehr effizient neue Prozesse und auf Kernelebene ist ein Thread auch nur wenig anders als ein Prozess. Der einzige echte Nachteil wären doch, so wie ich das sehe, höchstens Kontextwechsel.

Außerdem hängt doch auch viel an der Scheduler-Implementierung. Ich bezweifle, dass der Scheduler dieses Moduls wesentlich effizienter ist als der Scheduler des Linux-Kernels.

@Blackjack: Naja, ob ich dafür 3000 Coroutinen laufen lassen würde...
BlackJack

Coroutinen haben im Grunde keinen Scheduler bzw. in der Regel einen sehr einfachen. Die einzelnen Routinen stossen den Wechsel zu einer anderen Routine ja selbst an.

Warum keine 3000 Coroutinen? Der grosse Vorteil ist, dass jede Ameise (oder was immer man dort auch sonst Simulieren möchte) als eigenständiges kleines AI-Programm laufen kann, das beliebig komplex ist. Bei der Alternative, in der Hauptschleife immer auf allen 3000 Individuen eine Funktion aufzurufen, die einen kleinen Schritt macht, sieht man im Quelltext von den Individuen, den für das einzelne Individuum ja eigentlich linearen Programmablauf nicht so schön.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

lunar hat geschrieben:
veers hat geschrieben:Abgesehen davon ist es in einigen Fällen sogar schneller als echte Threads da der aufwand einen Thread zu erstellen relativ gross ist (Ja, kann mit Pooling gesenkt werden).
Ich habe keine Ahnung von Windows, allerdings glaube ich nicht, dass der Aufwand zum Erzeugen von Threads unter Linux sehr, sehr groß ist. Immerhin erzeugt fork() unter Unix sehr effizient neue Prozesse und auf Kernelebene ist ein Thread auch nur wenig anders als ein Prozess. Der einzige echte Nachteil wären doch, so wie ich das sehe, höchstens Kontextwechsel.
Das ist sicherlich so. Darum habe ich auch gesagt in einigen Fällen. Soweit ich weis verwendet Eve Online (Ein MMORPG), unteranderem deshalb Stackless Python/Tasklets. Das ist aber sicherlich ein extrem Beispiel ;)
Antworten