Multithreading Effizienz
-
Innerhalb von 40ms muss 2x ein 720p Bild konvertiert werden. Jede Konvertierung kostet auf meinem Intel Duo-Core 2.4 GHz ~6ms. >10ms zusammen ist zuviel und ich überlege durch Multithreading Zeit zu gewinnen, jedoch frage ich mich, ob es sich überhaupt lohnt. In einem ähnlichen Fall hat jemand OpenMP zur Parallelisierung der Schleifen verwendet.
-
Warum verlinkst du auf CairoImage::Load bei konvertiert? Laden != Konvertieren.
-
Weil die Bilddaten von einer von drei Frameserver APIs kommen, welche die Daten unterschiedlich speichern und die Grafikbibliothek Cairo wiederum einen anderen Format braucht.
Z.B. speichern die Frameserver APIs die Bilddaten bottom-top, während Cairo top-bottom erwartet, das Bild muss also ohnehin vertikal umgedreht werden. Desweiteren nutzt Cairo 4 Byte pro Pixel, auch ohne Alpha-Kanal, während Avisynth und DirectShow für RGB 3 Byte verwenden. Avisynth hat allerdings ein Padding nach jeder Reihe, usw. Das Laden führt also auch eine Konvertierung durch.
Die Gemeinsamkeit liegt bei den Schleifendurchgängen, welche ich gerne parallelisieren würde. Nur lohnt sich das in diesem Falle und der bereits kurzen Dauer?
-
beenchmarke es doch. einen openmp loop drüberzulegen ist ja nicht so schwer.
-
otze schrieb:
beenchmarke es doch. einen openmp loop drüberzulegen ist ja nicht so schwer.
Ich verwende nur Express Versionen des MSVC++, daher ist OpenMP nicht verfügbar. Die parallelen Schleifen mit Win32 Threads zu schreiben wollte ich heute Abend, falls wer spontan und aus Erfahrung eine Empfehlung geben könnte/würde.
-
Falls du VC++11 (VS 2012) verwendest, kannst du auch
std::threadeinsetzen. Darauf aufbauend kannst du High-Level-Routinen für parallelisierte For-Schleifen schreiben.
-
Nexus schrieb:
Falls du VC++11 (VS 2012) verwendest, kannst du auch
std::threadeinsetzen.Konnte nicht bereits MSVC++10 C++11?
Nexus schrieb:
Darauf aufbauend kannst du High-Level-Routinen für parallelisierte For-Schleifen schreiben.
Sowas in der Art hatte ich mir mit Win32 Threads bereits geschrieben:[1] [2]
Die Frage bleibt allerdings: lohnt es sich? Ziehe man eine Maschine mit mehr Kernen(=mehr Threads) in Betracht, würde es sich dann mehr oder weniger lohnen wegen der Kosten der Thread-Erstellung? Sind vielleicht 6ms zu wenig, um an Multithreading zu denken, schließlich kann es auch den Fall geben, dass statt einem 720p Bild mal ein 480p durchlaufen wird und damit die Aufgabe pro Thread noch geringer wird.
-
Bei OpenMP wäre ich mir recht sicher, dass das noch geht.
nbenbei: du meinst dass das Gesamtbild nur 720 Pixel hat? Oder ist es 720x720? Im ersten Fall liegt dein Problem woanders und deine Konvertierung ist müll. Das sollte nimals 6ms dauern Im zweiten Fall kannst du mit parallelisierung viel erreichen.
-
otze schrieb:
Bei OpenMP wäre ich mir recht sicher, dass das noch geht.
Nutzt OpenMP neben der Thread-Erstellung noch weitere Techniken zur Beschleunigung? Wäre es also weit empfehlenswerter als Win32 Threads zu erstellen?
otze schrieb:
du meinst dass das Gesamtbild nur 720 Pixel hat? Oder ist es 720x720?
Damit meine ich die Video-Auflösung von 1280x720 Pixeln.
otze schrieb:
Im ersten Fall liegt dein Problem woanders und deine Konvertierung ist müll. Das sollte nimals 6ms dauern
Ich habe diesen Wert als Schnitt der Ergebnisse von 100 Frames mit clock bekommen. Genauer waren es 5.65ms. Wie ich die Konvertierung nun günstiger schreiben könnte wüsste ich nicht, da memcpy bereits SSE verwendet und der Code schon ziemlich minimal ist.
otze schrieb:
Im zweiten Fall kannst du mit parallelisierung viel erreichen.
Welchen zweiten Fall meinst du?
-
//edit ahh ich seh erst jetzt, dass 720p keine Größ sondern ein Bildformat ist. hätte man dazu schreiben können :).
OpenMP verwendet Threadpools.
-
in Betracht, würde es sich dann mehr oder weniger lohnen wegen der Kosten der Thread-Erstellung
Es gibt auch Design-Patterns fuer parallele Aufgaben.