Python threading vs. multiprocessing im Linux

Basierend auf dieser Frage ich davon ausgegangen, dass die Schaffung neuen Prozess sollte fast so schnell wie erstellen neuen thread in Linux. Allerdings, kleiner test zeigte ganz anderes Ergebnis. Hier ist mein code: 

from multiprocessing import Process, Pool
from threading import Thread

times = 1000

def inc(a):
    b = 1
    return a + b

def processes():
    for i in xrange(times):
        p = Process(target=inc, args=(i, ))
        p.start()
        p.join()

def threads():
    for i in xrange(times):
        t = Thread(target=inc, args=(i, ))
        t.start()
        t.join()

Tests: 

>>> timeit processes() 
1 loops, best of 3: 3.8 s per loop

>>> timeit threads() 
10 loops, best of 3: 98.6 ms per loop

So, die Prozesse sind fast 40 mal langsamer zu erstellen! Warum ist es passiert? Ist es spezifisch für Python oder diese Bibliotheken? Oder habe ich es nur falsch interpretiert die Antwort oben?

UPD 1. Zu machen, mehr klar. Ich verstehe, dass dieses Stück code nicht wirklich vorstellen jede Parallelität. Das Ziel hier ist das testen die Zeit, die benötigt wird, um einem Prozess und einem thread. Der Einsatz von real-Parallelität mit Python kann man so etwas wie dieses: 

def pools():
    pool = Pool(10)
    pool.map(inc, xrange(times))

denen läuft wirklich viel schneller, als Gewinde-version.

UPD 2. Ich habe die version mit os.fork():

for i in xrange(times):
    child_pid = os.fork()
    if child_pid:
        os.waitpid(child_pid, 0)
    else:
        exit(-1)

Ergebnisse:

$ time python test_fork.py 

real    0m3.919s
user    0m0.040s
sys     0m0.208s

$ time python test_multiprocessing.py 

real    0m1.088s
user    0m0.128s
sys     0m0.292s

$ time python test_threadings.py

real    0m0.134s
user    0m0.112s
sys     0m0.048s
  • Gut, die Frage, die Sie verknüpft, ist der Vergleich der Kosten von nur aufrufen fork(2) vs. pthread_create(3), während Ihr code wird schon ein bisschen mehr. Wie über den Vergleich von os.fork() mit thread.start_new_thread()?
  • Ich konnte Sie nicht finden jede Art von join im thread Modul zu erstellen, ähnlich wie Prüfungen, aber auch im Vergleich zu high-level - threading version mit os.fork() ist noch viel langsamer. In der Tat, es ist das langsamste ist (wenn zusätzliche Bedingungen können die Leistung beeinflussen). Siehe mein update.
  • Sie einen mutex verwenden müssen, zu warten, bis der thread, wenn Sie mit der low-level - thread - Modul, welches, wie die höheren-Ebene threading Modul implementiert join(). Aber, wenn Sie nur versuchen die Zeit Messen, die es braucht, um erstellen Sie die neue Prozess/thread, dann sollten Sie nicht fordern join(). Siehe auch meine Antwort unten.
InformationsquelleAutor ffriend | 2013-07-02
  1. 5

    Die Frage, die Sie verknüpft, ist der Vergleich der Kosten von nur aufrufen fork(2) vs. pthread_create(3), während Ihr code wird schon ein bisschen mehr, z.B. über join() warten, bis die Prozesse/threads beenden.

    Wenn, wie du sagst...

    Das Ziel hier ist das testen die Zeit, die benötigt wird, um einem Prozess und einem thread.

    ...dann sollten Sie nicht warten, um Sie abzuschließen. Sie sollten mit test-Programme, die wie diese...

    fork.py

    import os
import time

def main():
    for i in range(100):
        pid = os.fork()
        if pid:
            #print 'created new process %d' % pid
            continue
        else:
            time.sleep(1)
            return

if __name__ == '__main__':
    main()

    thread.py

    import thread
import time

def dummy():
    time.sleep(1)

def main():
    for i in range(100):
        tid = thread.start_new_thread(dummy, ())
        #print 'created new thread %d' % tid

if __name__ == '__main__':
    main()

    ...die geben die folgenden Ergebnisse...

    $ time python fork.py
real    0m0.035s
user    0m0.008s
sys     0m0.024s

$ time python thread.py
real    0m0.032s
user    0m0.012s
sys     0m0.024s

    ...also es gibt nicht viel Unterschied in der Zeitpunkt der Erstellung von threads und Prozessen.

    • Aber nicht Ihre fork.py nur neue threads erstellen und beenden, ohne zu warten, für die Kind-Prozesse abgeschlossen?
    • Auch, starten Sie den nächsten thread/Prozess ohne zu warten, für den vorherigen zu beenden, so dass Sie gleichzeitig laufen, während es scheint, um korrekt zu starten nacheinander, um zu vermeiden, GIL und all solche Dinge.
    • Nun, Ihre Frage sagte (Hervorhebung von mir) "ich bin davon ausgegangen, dass erstellen neue Prozess sollte fast so schnell wie die Schaffung neuer thread in Linux" , und es ist. Der springende Punkt bei der Verwendung von threads für Nebenläufigkeit, also, was wäre der Punkt der Laufenden threads nacheinander? Was genau versuchst du hier zu erreichen?
    • Ich bin versucht zu vergleichen, der Aufwand für das verlegen neuer thread und neue Verfahren. Ich spreche von der Schöpfung bis zu separaten thread/Prozess von anderen details wie GIL, Funktionsaufrufe, etc.. Aber natürlich, fügen Sie es zurück, ist ebenfalls von Bedeutung. Laufen viele threads/Prozesse, die sequenziell ist nur ein weiterer Weg, um herauszufinden, meine Zeit. Siehe mein erstes update für details.
    • Nun, wenn man die tear-down-Zeit, dann sind Prozesse, die dauern ein bisschen länger als das Gewinde, aber der Aufwand ist immer noch im Millisekundenbereich, so oder so. In der Praxis ist jedoch, wenn die Menge der Zeit es braucht, um set-up und tear-down-ein Prozess/thread ist größer als die Zeit, die der Prozess/thread arbeitet, dann gibt ' s nicht viel Punkt, wenn Sie Sie verwenden. Ansonsten, der Aufwand ist irrelevant, und die Wahl zwischen den beiden sollte sich auf welche mehr für das eigentliche Ziel, das Sie versuchen zu erreichen.
    • Auch, gegeben, dass die verlinkte Frage ist nur die Messung der set-up-Zeit, und ignorieren die tear-down-Zeit, dann würde das erklären, die Diskrepanz zwischen Ihren Ergebnissen und den Ergebnissen aus den Beispielen in dieser Antwort. Ich dachte, deine Frage war zu erklären ist diese Diskrepanz, die ich dachte, ich hatte. Also wenn das nicht Ihre Frage ist, was ist dann?
    • Nur als Beispiel-Anwendung oder ein framework, dass erzeugt eine Menge von threads/Prozessen, die alle die Zeit, etwas ähnlich zu dem, was Erlang hat. Wenn die Prozesse waren wirklich leicht, man könnte Sie nutzen wollen, anstelle von threads. Aber wenn man (relativ) großen Aufwand, es wäre besser, mehr Aufwand auf threads statt. Natürlich gibt es Möglichkeiten, um alle Probleme überwinden, aber es ist schlimmer, zu wissen, dass solche details im Vorfeld. Auch, vergessen Sie nicht über GIL, die alle über threads vs. Prozesse. Trotzdem, Antworten und Kommentare geklärt, so dass ich akzeptiere deine Antwort als die detaillierte. Danke.
    • Ich sehe. Naja, die Schaffung von threads und Teilprozesse haben einen ziemlich großen Aufwand, so dass in der Praxis würde ich wahrscheinlich versuchen zu vermeiden, die Schaffung einer "Anwendung oder framework, das schafft viele threads/Prozesse die ganze Zeit", und verwenden Sie ein pool-basiertes Modell statt. Die GIL ist eine Art Schmerz mit Python, aber Sie können dies vermeiden, indem Teilprozesse mit IPC, oder die Verwendung von threads, die call-in-C-Bibliothek (z.B. mit ctypes), um die meiste Arbeit zu tun.

    InformationsquelleAutor Aya
  2. 2

    Ja, es ist wahr. Ein neuer Prozess gestartet wird (die sogenannte heavyweight process) ist teuer.

    Als übersicht ...

    Muß das Betriebssystem (in dem Fall linux) Gabel der erste Prozess, einrichten der Buchführung, für die neue Prozess, die neue stack, tun Sie den Kontext wechseln, kopieren Speicher, der verändert wird, und reißen alles runter, wenn der neue Prozess gibt.

    Den thread reserviert einen neuen stack-und thread-Struktur, nicht den Kontext wechseln, und gibt, wenn die Arbeit getan ist.

    ... das ist, warum wir threads.

    • Sie bekam es von hinten. ein Prozess ist einfach ein Prozess. ein thread ist ein leichtgewichtiger Prozess 🙂 ich denke, man kann nennen, ein Prozess, ein Schwergewicht thread, aber ich glaube nicht, dass jemand das tut. was ist ein Schwergewicht-Prozess?
    • Seufz. Wenn Sie nicht wissen, sth, dann zumindest konnte man es Google. Versuchen Sie Googeln "schwergewichtige Prozesse" und sehen, ob wer macht das.
    InformationsquelleAutor andy256
  3. 1

    In meiner Erfahrung gibt es einen bedeutenden Unterschied zwischen dem erstellen eines Threads (mit pthread_create) und die Verzweigung eines Prozesses.

    Beispielsweise erstellte ich einen C-test ähnlich wie die python-test-thread mit code wie diesem:

    pthread_t thread; 
pthread_create(&thread, NULL, &test, NULL); 
void *res;
pthread_join(thread, &res);

    und das Prozess-forking-code wie folgt:

    pid_t pid = fork();
if (!pid) {
  test(NULL);
  exit(0);
}         
int res;
waitpid(pid, &res, 0);

    Auf meinem system die code-forking dauerte etwa 8 mal so lange zum ausführen.

    Jedoch, es ist erwähnenswert, dass die python-Implementierung ist sogar noch langsamer - bei mir war es ungefähr 16 mal so langsam. Ich vermute, dass es ist, weil zusätzlich zu den regelmäßigen Aufwand der Erstellung eines neuen Prozesses, es ist auch mehr python-overhead im Zusammenhang mit dem neuen Verfahren zu.

    InformationsquelleAutor James Holderness
Schreibe einen Kommentar