Vor ein paar Jahren, in der Windows-Umgebung, habe ich einige Tests gemacht, indem ich mehrere Instanzen der CPU-Berechnung intensive + Speicherzugriff intensive + E / A-Zugriff intensive Anwendung ausgeführt haben. Ich habe zwei Versionen entwickelt: Eine läuft unter Multi-Processing, eine andere läuft unter Multi-Threading.
Ich habe festgestellt, dass die Leistung für Multi-Processing viel besser ist. Ich habe woanders gelesen (aber ich kann mich nicht an die Seite erinnern).
Was besagt, dass der Grund dafür ist, dass sie unter Multi-Threading für eine einzelne Speicher-Pipeline und I / O-Pipeline "kämpfen", was die Leistung im Vergleich zur Multi-Verarbeitung verschlechtert
Ich kann diesen Artikel jedoch nicht mehr finden. Ich frage mich, bis heute, ob die unten immer noch wahr sind?
In Windows mit dem Algorithmus Code läuft unter Multi-Processing, dort ist ein High Chance, dass die Leistung wird besser als Multi-Threading.
Es hängt davon ab, wie viel die verschiedenen Threads oder Prozesse (ich werde den Sammelbegriff "Aufgaben" für beide verwenden) kommunizieren müssen, besonders durch die gemeinsame Nutzung von Speicher: das ist einfach, billig und schnell für Threads, aber nicht überhaupt für Prozesse, also, wenn viel davon los ist, wette ich, dass die Performance von Prozessen nicht ist, um Threads zu schlagen.
Außerdem sind Prozesse (besonders unter Windows) "schwerer", um loszulegen. Wenn also viele "Task-Starts" auftreten, können Threads Prozesse in Sachen Leistung leicht übertreffen.
Als nächstes können Sie CPUs mit "Hyperthreading" haben, die (mindestens) zwei Threads auf einem Kern sehr schnell ausführen können - aber keine Prozesse (da die "Hyperthread" -Threads keine eindeutigen Adressräume verwenden können) - noch ein weiterer Fall, in dem Threads leistungsmäßig gewinnen können.
Wenn keine dieser Überlegungen zutrifft, sollte das Rennen sowieso nicht besser sein als ein Gleichstand.
Ich bin mir nicht sicher, was das Zitat überhaupt bedeutet. Es ist sehr nah an Unsinn.
Die primäre Sache, die prozessinterne Threads teilen, ist der Adressraum des virtuellen Speichers.
Ich glaube nicht, dass das wahr ist. Im Allgemeinen läuft eine Multithread-Anwendung schneller als die gleiche Anwendung, die als mehrere Prozesse unter Windows entwickelt wurde. Es gibt verschiedene Gründe, warum Ihr Test im Fall mehrerer Prozesse besser abgeschnitten hat.
Das erste, was mir in den Sinn kommt, ist falsches Teilen. In Ihren Multithread-Tests haben die Threads unbeabsichtigt Cache-Zeilen gemeinsam genutzt. Dies geschieht, wenn verschiedene Threads auf verschiedene Speicherorte zugreifen, die physisch nahe beieinander liegen (innerhalb weniger Bytes). Dies bewirkt, dass die zwei CPUs zwei kontinuierlich über die gleiche Cache-Zeile konkurrieren, und dies beeinträchtigt die Leistung stark. Das kann im Multiprozess-Fall nicht passieren, weil die Prozesse völlig getrennte Adressräume haben.
Ich fand das auch wahr. aber ich denke, es hat etwas mit der Planung zu tun. Denn wenn Sie es lange genug laufen, ist die Multi-Prozesse genauso schnell wie Multi-Threads. diese Zahl ist ungefähr 10 Sekunden. wenn der Algorithmus für 10 Sekunden ausgeführt werden soll. Die Multi-Prozesse sind so schnell wie Multi-Thread. aber wenn es nur für weniger als 1 Sekunde ausgeführt werden muss. Multi-Prozesse sind viel, viel schneller als Multi-Thread.
Tags und Links c++ multithreading windows architecture multiprocess