Grid Engine / Multithreading / Multi-Core / Multi-CPU: Wie entscheidet man sich für eine optimale Anzahl von Threads?

821
gojira

Ich verwende ein Programm (*) unter Unix / Linux (verschiedene Varianten) auf verschiedenen Servern und Clustern. Das Programm unterstützt Multithreading. Ich kann genau angeben, wie viele Threads ich über die Befehlszeilenoption haben möchte.

Wie kann ich generell bestimmen, wie viele Threads ich für das Multithreading angeben muss (um die maximale Geschwindigkeit zu erreichen)?

Sollte die Anzahl der Threads niedriger / gleich der Anzahl der Hardwarethreads sein, die die jeweilige CPU unterstützt? Gibt es eine Faustregel oder einen Ausgangspunkt?

Wenn ja, wie kann ich herausfinden, wie viele Hardware-Threads eine CPU unterstützt?

Ich sollte auch erwähnen, dass die Computer, auf denen ich normalerweise arbeite, mehrere CPUs mit jeweils mehreren Kernen haben. Unklar, wenn ein Kern = ein Thread ist.

(*) Das Programm, das ich verwende, ist bwa, ein Programm zum Abgleichen von DNA-Sequenzen. Aber meine Frage ist allgemeiner Natur.

0

2 Antworten auf die Frage

1
Journeyman Geek

Nun, es gibt ein paar Teile zu dieser Frage - im Allgemeinen ist es eine gute Faustregel, nicht mehr Threads auszuführen, als Sie über logische Prozessoren verfügen - obwohl dies normalerweise für das gesamte System gilt und von der Auslastung abhängen kann. Um herauszufinden, wie viele physische Prozessorkerne Sie haben, können Sie verwenden cat /proc/sysinfo. Es wird eine Reihe von Zeilen für jeden logischen Kern gedruckt. Scrollen Sie also nach unten und schauen Sie sich den letzten an (ich habe 8 fast identische auf meinem Quad-Core, HT-System).

processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz stepping : 9 microcode : 0x16 cpu MHz : 3401.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 6819.66 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:  

Ich wähle die wichtigsten Zeilen hier aus: physische id: 0 (dies ist der erste Socket. Wenn Sie mehr als einen Socket verwenden, überprüfen Sie die Prozessor- und CPU-Kerne für jedes physische JD. Wenn dies eine Zahl ist, die größer als 0 ist, haben Sie mehrere Steckdosen)

Prozessor: 7 (diese Zahl beginnt mit 0 bis n-1, dies ist der 8. logische Kern in seinem Socket - betrachtet die größte Anzahl, die Sie für einen Satz von Werten haben, die eine physische ID gemeinsam nutzen)

CPU-Kerne: 4 (Ich habe 4 physische Kerne - dies ist für jeden Kern gleich, und da SMP im Allgemeinen identische Kerne verwendet, sollte dies auf einem Dual-Socket-System gleich sein.)

Mein Prozessor sollte mir erlauben, 8 Threads gleichzeitig auszuführen, wobei ein Kern pro Thread angenommen wird. Das heißt, abhängig von der Laufzeit und anderen Faktoren, die Sie möglicherweise mit mehr erreichen können

SO hat einige Fragen zu diesem Thema, und wenn Sie zwei davon auswählen, deuten die Antworten auf diese Frage darauf hin, dass ein Thread pro logischem Kern eine gute Idee ist, obwohl dies darauf hindeutet, dass Sie möglicherweise höher steigen können. Unglücklicherweise lautet die Antwort, mit einem Thread pro Prozess zu beginnen und höher zu stimmen - was eine wahnsinnig hohe Anzahl von Threads sein kann, wenn sie nicht lange laufen und speicherhungrige Threads sind.

Danke, das liefert sehr gute Argumente. Nur um hinzuzufügen: In meinem Fall habe ich tatsächlich (ein paar Hundert) lang laufende, speicherhungrige Threads. gojira vor 10 Jahren 0
0
Brian

Grid Engine ist ein spezifisches Programm, das Ihre Frage zu einer Frage macht, wenn Sie es tatsächlich verwenden. Es geht darum, Ressourcen und Jobs systemübergreifend zu verwalten, sodass Endbenutzer nicht so detailliert denken müssen.

Einführung

Die Oracle Grid Engine-Software ist ein DRM-System (Distributed Resource Management), das eine höhere Auslastung, einen besseren Workload-Durchsatz und eine höhere Produktivität der Endbenutzer durch vorhandene Rechenressourcen ermöglicht. Durch die transparente Auswahl der Ressourcen, die für jedes Arbeitssegment am besten geeignet sind, kann die Oracle Grid Engine-Software die Arbeitslast effizient auf den Ressourcenpool verteilen und gleichzeitig die Endbenutzer vor dem inneren Arbeiten des Rechenclusters schützen

Ref: Anleitung für Anfänger auf der Oracle Grid Engine-Website .

Ich muss nicht zustimmen. Grid Engine kann keine anwendungsinterne Unterstützung für Multithreading übernehmen. Das Aufrufen von Programmen einmal pro Thread führt zu Mehraufwand. Daher kann Multithreading auf Anwendungsebene wünschenswert sein. Daher sind Grid Engine und Multithreading auf Anwendungsebene kein Widerspruch. gojira vor 10 Jahren 0