Python Skript aufrufen Main vs. Subprocess

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.
Antworten
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

@BlackJack: ich beziehe mich hier auf CPython, also das echte mit GIL :wink:
Parallelität gibt es dort erst bei Verwendung des ProcessPoolExecutor; also Multiprocessing. Wichtig, wenn die Anwendung CPU-Bound ist. Obgleich moderne Prozessoren inzwischen so schnell sind, dass es in solchen Fällen zumeist sinnvoller ist, kompilierte Libraries einzubinden, statt weitere Python-Prozesse zu starten.
Anders sieht es bei I/O lastigen Anwendungen aus — hier können Threads und async sinnvoll zum Einsatz kommen. Jedoch wird in beiden Fällen innerhalb eines Prozesses Python-Code nicht parallel ausgeführt. Aber was erzähle ich Dir ...
Benutzeravatar
DeaD_EyE
User
Beiträge: 1017
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Man sollte sich den Vortag mal ansehen um zu verstehen was der GIL für komische Effekte hat: https://www.youtube.com/watch?v=Obt-vMVdM8s
Ohne den GIL wäre Python außerdem viel langsamer. Da sich hier die meisten auf die CPython Implementierung beziehen, ist die Aussage schon richtig, dass man CPU-Bound Tasks nicht in Threads einbinden sollte.

Fakt ist, dass bei der CPython Implementierung nur eine Python-Instruktion parallel ausgeführt wird. Das ändert man auch nicht mal eben.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
Benutzeravatar
snafu
User
Beiträge: 6738
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Threads sind in CPython erst dann eine schlechte Idee, wenn man damit CPU-lastige Abläufe auf mehrere Kerne aufteilen will, um sie zu beschleunigen. Die laufen dann womöglich tatsächlich auf 2 Kernen, aber es bringt einem nichts, weil durch Pythons GIL trotzdem immer ein Thread warten muss bis der andere den GIL freigegeben hat. Das bedeutet nicht, dass der erste Thread erstmal komplett fertig sein muss. Es kann durchaus mehrmals pro Sekunde automatisch zwischen den Threads gewechselt werden (abhängig von der Performance des Rechners und was genau gemacht werden muss). Aber am Ende wird genau soviel Zeit verbraucht wie bei einer sequenziellen Ausführung der Aufgaben ohne Threads (aufgrund des Verwaltungsaufwands sogar etwas mehr). Wenn man Threads aber benötigt, weil z.B. der Benutzer noch etwas anderes im Programm tun darf, während eine Sounddatei läuft oder sowas, dann sind Threads eine gute Idee.
Benutzeravatar
DeaD_EyE
User
Beiträge: 1017
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Threads bei IO stellen auch ein großes Problem dar. Ich denke kaum, dass hier jemand mal einen Server mit Threading in Python programmiert hat, der mehr als 10k Requests pro Sekunde schafft. Die Threads sind übrigens echte Threads. Jeder sollte wissen, dass auch Threads Systemressourcen verbrauchen. Prozesse benötigen noch mehr Ressourcen als Threads.

Für kleine Anwendung sind Threads geeignet. Threading fehlerfrei zu programmieren ist nochmal eine ganz andere Hausnummer. Das kann so weit gehen, dass ein Programm komplett mit Threads programmiert worden ist und am Ende stellt sich heraus, dass das komplette Programm durch die ganzen Locks Synchron abläuft.

Für die genannten Beispiele eignen sich Threads natürlich.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
Antworten