☰

Schlechter Parallelverarbeitungsgewinn auf einigen Linux-Rechnern, gut auf anderen

tag-icon • tag-icon parallel-processing
Schlechter Parallelverarbeitungsgewinn auf einigen Linux-Rechnern, gut auf anderen

Ich messe die Laufzeit eines komplexen Signalverarbeitungsalgorithmus, der in C geschrieben ist, auf mehreren verschiedenen Computern, die alle unter Linux laufen. Der Code wird teilweise durch einige meiner eigenen Methoden unter Verwendung der pthreads-Bibliothek und durch die parallele Verarbeitung, die das FFTW-Paket ermöglicht, parallelisiert. Drei der vier Computer zeigen die erwartete Verkürzung der Ausführungszeit, wenn der Parallelitätsfaktor P von 1 auf die Anzahl der physischen Kerne auf der Maschine ansteigt. Das Problem ist, dass eine der Maschinen das entgegengesetzte Verhalten zeigt: Der Wechsel von P=1 auf P=2 führt zu einer Verlängerung der Ausführungszeit.

Der Code ist auf allen vier Rechnern identisch, die Hardware und die Betriebssysteme jedoch nicht. Hyperthreading ist aktiviert. Alle haben große RAMs.

toren: Ubuntu 18.04.5, 4.15.0-122-generic, 4 physische Kerne, Xeon(R) CPU E3-1535M v5 @ 2,90 GHz, gcc Version 7.5

[email protected]>./ssca2_parallelism 
P = 1   ssca2: elapsed PROGRAM TIME 1.025756e+01
P = 2   ssca2: elapsed PROGRAM TIME 7.500780e+00
P = 4   ssca2: elapsed PROGRAM TIME 6.246292e+00
P = 8   ssca2: elapsed PROGRAM TIME 5.483851e+00
P = 16   ssca2: elapsed PROGRAM TIME 7.457973e+00
P = 32   ssca2: elapsed PROGRAM TIME 8.497999e+00
P = 64   ssca2: elapsed PROGRAM TIME 1.035557e+01

zwölf: Fedora Core 31, 5.8.15-101.fc31.x86_64, 12 physische Kerne, Xeon(R) CPU X5650 @ 2,67 GHz, gcc Version 9.3

[email protected]>./ssca2_parallelism 
P = 1   ssca2: elapsed PROGRAM TIME 1.833605e+01
P = 2   ssca2: elapsed PROGRAM TIME 1.171951e+01
P = 4   ssca2: elapsed PROGRAM TIME 8.526402e+00
P = 8   ssca2: elapsed PROGRAM TIME 7.255262e+00
P = 16   ssca2: elapsed PROGRAM TIME 1.268390e+01
P = 32   ssca2: elapsed PROGRAM TIME 1.188247e+01
P = 64   ssca2: elapsed PROGRAM TIME 1.417718e+01

Flash: Fedora Core 31, 5.8.15-101.fc31.x86_64, 28 physische Kerne, Xeon(R) CPU E5-2697 v3 @ 2,60 GHz, gcc Version 9.3

[email protected]>./ssca2_parallelism 
P = 1   ssca2: elapsed PROGRAM TIME 1.462457e+01
P = 2   ssca2: elapsed PROGRAM TIME 1.066421e+01
P = 4   ssca2: elapsed PROGRAM TIME 8.244503e+00
P = 8   ssca2: elapsed PROGRAM TIME 7.694590e+00
P = 16   ssca2: elapsed PROGRAM TIME 1.030944e+01
P = 32   ssca2: elapsed PROGRAM TIME 1.079129e+01
P = 64   ssca2: elapsed PROGRAM TIME 1.413906e+01

barra: Ubuntu 18.04.4, 5.4.0-52-generic #57~18.04.1-Ubuntu, 8 physische Kerne, Xeon(R) W-3225 CPU @ 3,70 GHz, gcc Version 7.5

[email protected]>./ssca2_parallelism 
P = 1   ssca2: elapsed PROGRAM TIME 8.891541e+00
P = 2   ssca2: elapsed PROGRAM TIME 1.006297e+01
P = 4   ssca2: elapsed PROGRAM TIME 8.619259e+00
P = 8   ssca2: elapsed PROGRAM TIME 7.233214e+00
P = 16   ssca2: elapsed PROGRAM TIME 7.765741e+00
P = 32   ssca2: elapsed PROGRAM TIME 8.301655e+00
P = 64   ssca2: elapsed PROGRAM TIME 1.114389e+01

Ich habe versucht, den Kernel von Barra auf 4.15 zurückzusetzen, aber das Ergebnis ist ähnlich.

Der Code ist auf allen identisch, ich verwende zum Kompilieren auf allen gcc mit demselben Makefile (Compilerschalter).

Irgendwelche Ideen, warum Barra sich nicht wie die anderen verhält?

Danke,

C

Antwort1

Das Ändern der CPU-Governor-Einstellungen von „Powersave“ auf „Performance“ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor hat das Problem gelöst.

verwandte Informationen