wie teilt man das Programm vollständig nutzen zu können, multi-CPU, multi-Core und hyper-Threading?
Ich habe eine Reihe von Befehlen für die gen-sequecing.
Zum Beispiel:
msclle_program -in 1.txt
msclle_program -in 2.txt
msclle_program -in 3.txt
.........
msclle_program -in 10.txt
diese Befehle sind unabhängig von einander.
Umwelt ist Linux Desktop, Intel Core i7(4 core/8 Threads)×7, 12G Speicher
Kann ich teilen diese Befehle in verschiedene n.sh-Programmen und führen Sie gleichzeitig.
Meine Frage ist Wie kann ich vollständig nutzen, multi-CPU, multi-Core und hyper-Threading, um das Programm schneller laufen?
Genauer gesagt, , wie viele Programm-Dateien sollte ich in split?
Meine eigenen Verständnis ist:
- aufgeteilt in 7 Programm-Dateien. Also jede CPU auf 100% laufen ein Programm
- Mit einer CPU, die CPU nutzt die multi-core-und multi-thread von allein.
Ist es Wahr?
vielen Dank für ur Kommentare.
Dies ist nicht zu erklären, richtig, so bin ich nur verlassen Sie es als Kommentar: Sie sollten laufen 8 Instanzen des Programms in vollem Umfang nutzen Ihre CPU, weil Sie 8 "Kerne" (dies wird vorausgesetzt, eine einzige Instanz zu sättigen, eine Kern - Ihr Programm ist CPU-bound).
Es hängt von verschiedenen Faktoren ab; das beste, was zu tun ist, führen Sie tests mit unterschiedlichen Anzahlen von gleichzeitigen Prozessen und zeichnen Sie auf ein Diagramm. Sie sollten sehen, welche Zahl ergibt die beste performance auf Ihrer hardware.
Ich habe 7 real - CPU. So konnte ich aufgeteilt in 7*8 Dateien und jede CPU hat 8 Programme?
Die Sache ist, Ihr computer ist nicht nur eine Reihe von CPUs, die in einem Vakuum. Es gibt auch RAM, RAM und caches, und der OS, und das OS das Kontext-switching-overhead und die Festplatte(N), und das Netzwerk, und so weiter. Konflikte für jede dieser Ressourcen kann Auswirkungen auf die Leistung in einer Weise, die nicht leicht vorhersehen. Das ist, warum es keinen Ersatz für tatsächlich versucht, verschiedene Ebenen von Parallelität und Messung Ihrer performance.
Es hängt von verschiedenen Faktoren ab; das beste, was zu tun ist, führen Sie tests mit unterschiedlichen Anzahlen von gleichzeitigen Prozessen und zeichnen Sie auf ein Diagramm. Sie sollten sehen, welche Zahl ergibt die beste performance auf Ihrer hardware.
Ich habe 7 real - CPU. So konnte ich aufgeteilt in 7*8 Dateien und jede CPU hat 8 Programme?
Die Sache ist, Ihr computer ist nicht nur eine Reihe von CPUs, die in einem Vakuum. Es gibt auch RAM, RAM und caches, und der OS, und das OS das Kontext-switching-overhead und die Festplatte(N), und das Netzwerk, und so weiter. Konflikte für jede dieser Ressourcen kann Auswirkungen auf die Leistung in einer Weise, die nicht leicht vorhersehen. Das ist, warum es keinen Ersatz für tatsächlich versucht, verschiedene Ebenen von Parallelität und Messung Ihrer performance.
InformationsquelleAutor teloon | 2011-01-20
Du musst angemeldet sein, um einen Kommentar abzugeben.
Antwort darauf ist nicht einfach oder unkompliziert und die Aufteilung der Aufgabe in ein Programm pro CPU ist wahrscheinlich nicht optimal und kann in der Tat sein arm oder sogar sehr arm.
Erste, wie ich es verstehe, haben Sie sieben quad-core-CPUs (vermutlich sind es acht, aber Sie sparen Sie eine für das OS?). Wenn Sie eine single-threaded-Prozess auf jeder CPU, die Sie verwenden werden, einzelne Threads auf einem single-core. Die anderen drei Kerne und alle Hyper-Threads werden nicht verwendet.
Hardware und OS nicht aufspalten eines einzigen Threads über mehrere Kerne.
Konnte man jedoch vier single-threaded Prozesse pro CPU pro core) oder sogar acht (eine pro hyperthread). Ob diese optimal ist, hängt von der Arbeit, die geleistet wird durch die Prozesse, insbesondere die working set-Größe-und-memory-access-patterns, und auf der hardware-cache zu treffen; die Anzahl der Ebenen von cache -, Ihre Größe und Ihre Aufteilung. Auch die NUMA-Anordnung der Kerne berücksichtigt werden muss.
Im Grunde genommen, ein extra thread muss dir Recht geben, ein bisschen Geschwindigkeit-bis zu überwiegen, was es Kosten kann Sie in den cache-Auslastung, Arbeitsspeicher zugreift und die Störung des pre-fetching.
Darüber hinaus, da die Auswirkungen des working set bei überschreitung bestimmter caching Grenzen tiefgreifend ist, scheint, was gut für sagen wir einen oder zwei Kerne, kann erschreckend für vier oder acht, so kann man gar nicht Experimentieren mit einem Kern und übernehmen die Ergebnisse sind nützlich, über acht.
Mit einem kurzen Blick, ich sehe i7 Prozessor hat einen kleinen L2-cache und einen großen L3-cache. Ihre Daten-set, ich würde mich nicht Wundern, wenn es gibt eine Menge von Daten verarbeitet werden. Die Frage ist, ob oder nicht, es wird sequentiell abgearbeitet wird (z.B. wenn dieses Verfahren wirksam sein wird). Wenn die Daten nicht sequentiell abgearbeitet wird, können Sie besser tun, durch die Verringerung der Anzahl der gleichzeitigen Prozesse, so dass Ihre arbeiten-sets neigen dazu, innerhalb der fit der L3-cache. Ich vermute, wenn Sie acht oder sechzehn Prozesse, der L3-cache wird gehämmert - übergelaufen. OTOH, wenn Ihre Daten zugreifen ist nicht sequenziell, der L3-cache prolly ist nicht zu retten Sie trotzdem.
InformationsquelleAutor
Können Sie laichen mehrere Verfahren und weisen Sie anschließend jeder Prozess auf eine cpu.
Sie können taskset -c zu tun.
Haben eine rollende Anzahl und Schrittweite angeben, die Prozessor-Anzahl.
InformationsquelleAutor Raghuram
Dies ist etwa richtig: wenn Sie 7 single-threaded Programme und 7 Einheiten zur Verarbeitung, dann wird jeder von Ihnen hat ein thread ausgeführt werden. Dies ist optimal: weniger Programme, und einige Einheiten zur Verarbeitung wäre müßig; mehr Programme, und die Zeit würde verschwendet werden, um im Wechsel zwischen Ihnen. Obwohl, wenn Sie 7 quad-core-Prozessoren, dann wird die optimale Anzahl von threads (aus "CPU-bound-Perspektive") wäre 28. Das ist vereinfacht, denn in der Realität gibt es andere Programme um gemeinsam die CPU.
Nicht. Ob oder nicht alle Kerne sind in der single-CPU oder nicht, macht kaum einen Unterschied (es macht einen Unterschied in der Zwischenspeicherung, obwohl). Trotzdem, der Prozessor nichts multithreading durch seine eigenen. Es ist der Programmierer job. Das ist, warum Programme schneller geworden, sehr anspruchsvoll heute: bis etwa 2005 oder so, war es kostenlos Reiten, da die Taktfrequenzen wurden stetig steigenden, aber jetzt ist die Grenze erreicht ist, und die Beschleunigung der Programme erfordert die Spaltung in der wachsenden Anzahl von Verarbeitungseinheiten. Es ist einer der wichtigsten Gründe für die renaissance funktionaler Programmierung.
Wenn Sie 7 Stücke laufen in 7 Einheiten zur Verarbeitung, und jeder von Ihnen ist unabhängig von den anderen, und nichts anderes ausgeführt wird, dann wird es kein context-switching, weil es keinen überschuss Kontext-switch zwischen. Aber dann, sogar Ihr Betriebssystem ist sicherlich mit ganz wenigen threads auf seine eigene, so gibt es in der Praxis immer etwas context-switching.
InformationsquelleAutor Joonas Pulakka
Warum führen Sie als getrennte Prozesse? Prüfen der Ausführung von mehreren threads in einem Prozess statt, die sowohl der Speicherbedarf viel kleiner und geringer die Menge der scheduling-Prozess erforderlich.
Könnte man es betrachten diese Weise (ein bisschen zu stark vereinfacht, aber immer noch):
Betrachten Sie die Aufteilung Ihrer Arbeit in verarbeitbare Einheiten (PU). Sie wollen dann zwei oder mehr Kernen zu jedem Prozess ein PU in einer Zeit, so dass Sie nicht gegenseitig stören, und je mehr Kerne desto mehr Eiter, die Sie verarbeiten kann.
Den Aufwand für die Verarbeitung einer PU-Eingabe+Verarbeitung+Ausgabe (I+P+O). Da ist es wohl Einheiten zur Verarbeitung von großen memory-Strukturen, die vielleicht Millionen oder mehr die input-und output-meist mit Erinnerung zu tun. Mit einem core ist das kein problem, denn kein anderer Kern stört den Speicher zugreift. Mit mehreren Kernen das problem verschoben wird grundsätzlich auf die nächsten gemeinsamen Ressource, in diesem Fall die L3-cache geben-cache-Eingang (CI) und cache-output (CO). Mit zwei Kernen möchte man CI+CO gleich P/2 oder weniger, weil dann die beiden Kerne abwechseln konnten, der Zugriff auf die nächsten gemeinsamen Ressource (L3-cache) und nicht gegenseitig stören. Mit drei Kernen CI+CO werden müsste, P/3 und vier oder acht Kerne, die Sie brauchen würden, CI+CO gleich P/4 und P/8.
Also der trick ist, die Verarbeitung erforderlich ist für einen PU befinden sich vollständig in einen Kern und seine eigenen caches (L1 und L2). Je mehr Kerne Sie haben, desto größer die PUs sollten (in Bezug auf die I/O benötigt), so dass die PU-bleibt isoliert in seinem Kern so lange wie möglich und mit allen Daten, die Sie benötigt, verfügbar in den lokalen caches.
Um es zusammenzufassen: Sie wollen den Kernen zu tun, wie viel sinnvolle und effiziente Verarbeitung möglich, während die Auswirkungen auf die L3-cache-so wenig wie möglich, da der L3-cache ist der Engpass. Es ist eine Herausforderung, die zu erreichen eine solche balance aber keineswegs unmöglich.
Als Sie verstehen, dass die Kerne der Ausführung "traditionellen" multi-threaded Verwaltungs-oder web-Anwendungen (wo keine Pflege auch immer genommen wird: sparen auf L3 Zugriffe) ständig miteinander kollidieren, für den Zugriff auf den L3-cache und Ressourcen weiter aus. Es ist nicht ungewöhnlich für multi-threaded-Programmen, die auf mehrere Kerne langsamer vor, als wären Sie ausgeführt worden, die auf einzelnen Kernen.
Auch nicht vergessen, dass OS arbeiten schlägt in den cache (eine Menge). Teilt man das problem in einzelne Prozesse (wie ich oben erwähnt habe) Sie werden telefonisch in das Betriebssystem Schiedsrichter viel öfter als unbedingt notwendig.
Meine Erfahrung ist, dass die Existenz, die dos und don ' TS für das problem größtenteils unbekannt sind oder nicht verstanden.
Eine Reihe von Eiter ist im wesentlichen eine indizierte Speicher-Struktur, bei der alle spezifischen Daten eines PU gespeichert ist, in seiner eigenen Struktur. Daten für alle PUs sollten minimiert werden, (hoffentlich) invariant und Speicher zusammen (in der gleichen Speicherbereich). Die Zuordnung könnte sein, weisen Sie jedem verfügbaren Kern eine Teilmenge der indizierten Struktur. Vorzugsweise sollten Sie sein und zugreifen-in-sequence (hilft den cache). Ruft die Anzahl der PUs "nPUs" und mit (zum Beispiel) acht cores core 0 würde der Prozess der PU-Bereich 0 bis nPUs/8-1, core 1 nPUs/8 bis 2*(nPUs/8)-1, und so weiter.
InformationsquelleAutor Olof Forshell