☰

Parallele Verarbeitung langsamer als sequentielle?

tag-icon • tag-icon linux terminal performance imagemagick parallel-processing
Parallele Verarbeitung langsamer als sequentielle?

EDIT: Für alle, die in Zukunft darüber stolpern: Imagemagick verwendet eine MP-Bibliothek. Es ist schneller, verfügbare Kerne zu verwenden, wenn sie vorhanden sind, aber wenn Sie parallele Jobs haben, ist dies nicht hilfreich.

Führen Sie einen der folgenden Schritte aus:

  • erledigen Sie Ihre Aufgaben seriell (mit Imagemagick im Parallelmodus)
  • Setzen Sie MAGICK_THREAD_LIMIT=1 für Ihren Aufruf der betreffenden ImageMagick-Binärdatei.

Indem ich Imagemagick nur auf einen Thread beschränkte, verlangsamte es sich in meinen Testfällen um 20–30 %, was aber bedeutete, dass ich problemlos einen Job pro Kern ausführen konnte, was zu einer deutlichen Nettoleistungssteigerung führte.

Ursprüngliche Frage:

Beim Konvertieren einiger Bilder mit ImageMagick ist mir ein etwas seltsamer Effekt aufgefallen. Die Verwendung von xargs war deutlich langsamer als eine Standard-for-Schleife. Da sich xargs, das auf einen einzelnen Prozess beschränkt ist, wie eine for-Schleife verhalten sollte, habe ich das getestet und festgestellt, dass es ungefähr gleich ist.

Somit haben wir diese Demonstration.

  • Quad-Core (AMD Athalon X4, 2,6 GHz)
  • Funktioniert vollständig auf einem Tempps (insgesamt 16 GB RAM, kein Swap)
  • Keine weiteren größeren Belastungen

Ergebnisse:

/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 1 convert -auto-level

real        0m3.784s
user        0m2.240s
sys         0m0.230s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 2 convert -auto-level

real        0m9.097s
user        0m28.020s
sys         0m0.910s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 10 convert -auto-level

real        0m9.844s
user        0m33.200s
sys         0m1.270s

Kann sich irgendjemand einen Grund vorstellen, warum das Ausführen zweier Instanzen dieses Programms in Echtzeit mehr als doppelt so lange dauert und in der Prozessorzeit mehr als zehnmal so lange, um dieselbe Aufgabe abzuschließen? Nach diesem ersten Schlag scheinen mehr Prozesse keinen so großen Effekt mehr zu haben.

Ich dachte, es könnte mit der Festplattensuche zu tun haben, also habe ich den Test komplett im RAM durchgeführt. Könnte es etwas damit zu tun haben, wie Convert funktioniert, und wenn mehr als eine Kopie gleichzeitig vorhanden ist, kann der Prozessor-Cache nicht so effizient genutzt werden oder so etwas?

BEARBEITEN: Bei 1000 x 769 KB großen Dateien ist die Leistung wie erwartet. Interessant.

/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 1 convert -auto-level

real    3m37.679s
user    5m6.980s
sys 0m6.340s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 1 convert -auto-level

real    3m37.152s
user    5m6.140s
sys 0m6.530s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 2 convert -auto-level

real    2m7.578s
user    5m35.410s
sys     0m6.050s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 4 convert -auto-level

real    1m36.959s
user    5m48.900s
sys     0m6.350s
/media/ramdisk/img$ time for f in *.bmp; do echo $f ${f%bmp}png; done | xargs -n 2 -P 10 convert -auto-level

real    1m36.392s
user    5m54.840s
sys     0m5.650s

Antwort1

Wie groß sind die Dateien, die Sie konvertieren möchten, im Vergleich zu Ihrem L1-Cache? Ihrem L2-Cache?

Ohne einen genaueren Blick in die Details werfen zu können, würde ich vermuten, dass Cache-Konflikte dazu führen, dass Ihre CPUs im Leerlauf laufen, während sie darauf warten, dass Daten erneut zwischengespeichert werden, weil die anderen Prozesse ständig wichtige Dinge aus dem schnellen Speicher verdrängen.

Siehe auchdiese Antwort habe ich auf Stack Overflow gegeben.

verwandte Informationen