Delphi und NUMA-Nodes

[Mavarik]

WOW... Na das ist doch mal eine detaillierte Frage...

Mit 2x Intel Xeon E3-2670 hast Du zwar genug Threads für 33 Cam's, hast Du es trotzdem mal mit 11 statischen Threads versucht und einer Queue?
ggf. auch je Thread einen statischen Speicher zu reservieren und diese nicht jedes mal zu erzeugen und wieder freizugeben?

Server und Virtualisierung ist das eine, ggf. könnte man den Server eine entsprechende Grafikkarte gönnen und zahlreiche Berechnungen auf der GPU machen.
GGf. ohne die Virtualisierung.

Grüsse Mavarik

[noob2k9]

Ich muss nur erkennen, dass sich etwas bewegt und in welche Richtung es sich bewegt.
Dazu sind je nach Bedarf auf dem Boden Streifen- und Schachbrettmuster aufgebracht wodurch die Aufgabe recht trivial wird.

Die Reduzierung der JPEG-Qualität hat nur geringfügig Einfluss auf den Download und das Dekodieren. Bei noch halbwegs brauchbarer Qualität halbiert sich die Dateigröße. Die Zeiteinsparung liegt jedoch bei lediglich ~5%. Dabei ist aufgefallen, dass die Kamera zwar auf Graustufen eingestellt ist, jedoch wird dennoch ein Farb-JPEG übermittelt (nur eben monochrom). Dadurch entsteht vermutlich unnötig Overhead beim Dekodieren, aber dass kann ich nicht beeinflussen ohne die Kameras zu ersetzen.

Beim detaillierten Logging hat sich nun herausgestellt, dass der Zeitanteil der Speicherzugriffe und -verschiebungen lediglich einen Bruchteil der Gesamtzeit ausmacht - der Löwenanteil geht auf Konto des Jpeg-Decoders. Ich werde hie rnochmal libJpeg versuchen.

Vorher werde ich noch einen Benchmark durchführen und die Zahl der parallelen Threads variieren. Die 2 CPUs haben jeweils 8 Cores, 16 Threads (logische Prozessoren). Ich vermute in den häufigen Kontextwechseln das Bottleneck, so dass 16 parallele Threads (Anwendung) - jeweils verteilt auf 1 Core / 2 logische Prozessoren - optimal sein könnten.

---

Der Speicher den ich zum Austausch zwischen den Prozessen verwende ist statisch. Der Input ist dynamisch, die 300kB sind jedoch in <1ms verschoben.
Die Anwendung wird gerade auf ThreadPools umgestellt, dass hat dann auch gleich den Vorteil, dass man problemlos wieder zurück auf eine feste Zuordnungen gehen kann.
Ich glaube nicht, dass eine zusätzliche GPU hier sinnvoll ist - was soll auf dieser berechnet werden? Das verschieben der Daten in den Speicher der GPU über eine relativ langsame Anbindung dauert dann ja länger als es direkt auf der CPU zu erledigen.

Die reine Bildverarbeitung dauert nichtmal 5ms, das Bildformat ist recht simpel: ein einfacher Bytestream zu dem die Breite und Höhe des Bildes gespeichert wird. Die Pixel werden als Graustufen / 1 Byte gespeichert.

[TiGü]

Besteht die Möglichkeit, dem Decoder zu sagen: Dekoriere nur die Y-Plane und ignoriere U- und V-Komponente?

[noob2k9]

Zitat von TiGü:

Besteht die Möglichkeit, dem Decoder zu sagen: Dekoriere nur die Y-Plane und ignoriere U- und V-Komponente?

Leider nein, ich werde morgen jedoch libJpeg integrieren - evtl. gibt es dort die Möglichkeit dies zu konfigurieren.



Der Benchmark hat gezeigt, dass die eingesetzte Bibliothek nicht skaliert - zumindest nicht so wie sie derzeit konfiguriert und kompiliert ist.
An den Affinitäten und Prioritäten wurde nichts verändert... keine feste Zuordnung von Threads zu Prozessoren oder NUMA-Knoten.

Der Wert gibt die Anzahl der dekodierten Jpegs / Minute an.

Mango (https://github.com/t0rakka/mango)
1: 696
2: 1002
4: 1204
8: 1207
16: 863
32: 784
64: 840
128: 824

nanoJpeg (http://www.emix8.org/static.php?page=nanoJpeg)
1: 415
2: 822
4: 1633
8: 3095
16: 5316
32: 7806
64: 7627
128: 7202

nanoJpeg ist nun nicht gerade für Performance bekannt, jedoch skaliert es wesentlich besser.
Bei 1-2 Threads hat Mango noch die Nase vorn, danach dreht sich das Bild gravierend um.
Mango kommt über 50%, scheint aber nicht an den NUMA-Knoten zu hängen da die Last über alle Threads verteilt wird.
nanoJpeg reizt ab 32 Threads volle 100% aus...

Ich werde den Test morgen mal mit der nativen Jpeg-Implementierung und libJpeg wiederholen

[TiGü]

Zitat von noob2k9:

Zitat von TiGü:

Besteht die Möglichkeit, dem Decoder zu sagen: Dekoriere nur die Y-Plane und ignoriere U- und V-Komponente?

Leider nein, ich werde morgen jedoch libJpeg integrieren - evtl. gibt es dort die Möglichkeit dies zu konfigurieren.

Nutzt du die bisherige libjpeg oder die Turbo-Variante?
https://libjpeg-turbo.org/
https://github.com/libjpeg-turbo/libjpeg-turbo

[noob2k9]

Zitat von TiGü:

Zitat von noob2k9:

Zitat von TiGü:

Besteht die Möglichkeit, dem Decoder zu sagen: Dekoriere nur die Y-Plane und ignoriere U- und V-Komponente?

Leider nein, ich werde morgen jedoch libJpeg integrieren - evtl. gibt es dort die Möglichkeit dies zu konfigurieren.

Nutzt du die bisherige libjpeg oder die Turbo-Variante?
https://libjpeg-turbo.org/
https://github.com/libjpeg-turbo/libjpeg-turbo

Ich habe jetzt libjpeg-turbo integriert, aktuellster Stand auf SF als Binary ist die Version 2.0.2. Die API scheint vollständig kompatibel zu sein. libjpeg-turbo ist jedoch auf dem Versionsstand 6.2b stehen geblieben (aktuell 9c), jedoch ist das kein Problem für mich. Die Performance ist gefühlt gut, Benchmark folgt.

Es scheint auch direkt die Möglichkeit zu geben den Farbraum festzulegen. Mit 8bit-Graustufen habe ich noch unschöne Effekte, welche ich weiter analysieren muss.

Es springt auch gleich Issue #325 "Provide memory manager overriding api" auf github ins Auge - ich scheine nicht allein zu sein mit diesem oder änhlichen Poblemen