[python-users] pyCologne Python User Group Köln - nächstes Treffen, Mittwoch, 11. Januar, 18:30 Uhr

[Christopher Arndt]

On 11.01.12 18:03, Oliver Frietsch wrote:
> Oh, das klingt spannend! Leider fehlt mir die Zeit, aber verrätst du uns
> hinterher, wer dabei gewonnen hat?

Na klar. Für den hier untersuchten Fall bei dem um es die Aufteilung
einer reinen CPU-Belastung durch *Python-Statements* auf mehrere
Threads/Prozesse geht, gewinnt eindeutig multiprocessing. Das liegt am
Global Interpreter Lock (GIL), durch den sich mehrere Threads, die viele
Python Statements ausführen, ins Gehege kommen.

Ihr könnt das selbst mit meinem Benchmarkscript nachvollziehen, indem
ihr es aus meinem SVN-Repository auscheckt:

$ svn co svn://svn.chrisarndt.de/talks/multiprocessing
$ cd multiprocessing
$ ./compile.sh # needs virtualenv !
$ ./testsuite.sh | tee -a results.txt

Ich habe das Skript eben nach der Sitzung nochmal ein wenig erweitert
und geändert, so dass man jetzt ein Python Statement übergeben kann,
dessen Ausführungszeit gemessen wird, jeweils in Singlethread-,
Multithread- und Multiprozess-Variante.

In der Testsuite wird zunächst eine Funktion mit einer längeren Schleife
mit Python-Statements, gemessen und dann das Statement
"time.sleep(0.01)" (als Beispiel einer Aufgabe die sich optimal
parallelisieren lässt). An den Ergebnissen sieht man, dass sich in der
ersten Variante die Threads gegenseitig behindern und in der zweiten
nicht, da hier beim Aufruf der Systemfunktion der GIL freigegeben wird.
Das schlechte Abschneiden der Threads liegt also zumindest nicht am
Aufwand die Threads zu erzeugen.

Um zu zeigen, dass das auch funktioniert, wenn die Threads was zu tun
haben, habe ich die zu messende Funktion "spamm" auch noch mal mittels
Cython in einer C-Extension implementiert. Auch hier sieht man, dass die
Ausführung mit mehreren Threads zumindest nicht wesentlich langsamer als
die Singlethread-Ausführung ist.

Viel Spaß beim Experimentieren,

Chris