SSE-Code läuft 30% schneller, zeigt aber bei Verwendung mehr als 20% CPU-Anstieg

8

Ich versuche, eine in VLC verwendete Routine zu optimieren, die den NV12-Frame in einen YV12-Frame konvertiert.

Für Hintergrundinformationen ist NV12 identisch mit YV12 mit der Ausnahme, dass die U- und V-Chroma-Ebene verschachtelt sind. Um also ein Format in ein anderes Format zu konvertieren, ist es nur eine Frage des Deinterleavings eines Kanals wie: UVUVUVUVUVUVU wird UUUUUUU VVVVVVV

Die Routine, die ich verbessern möchte, ist diese: Ссылка

Das Hauptproblem bei dieser Routine besteht nun darin, dass ein ausgerichteter Speichercache mit 16 Byte als Zwischenspeicher erforderlich ist Also entschachtelt die Routine zuerst die Daten in den Cache (4kB max) und kopiert dann das im Cache gefundene Ergebnis zurück in den Zielframe.

Ich habe diese Funktion neu geschrieben, so dass kein Cache benötigt wird, wenn SSE2 / 3-Anweisungen bei Bedarf auf nicht ausgerichteten Speicher angewendet werden und Befehle möglichst ausgerichteten Speicher verwenden.

Der Code ist wie folgt:

%Vor%

Jetzt, Benchmarking dieser Funktion allein, läuft es etwa 26% schneller auf einem i7-2600 CPU (ivybridge 3,4 GHz), ein wenig schneller auf einem i7-4650U (haswell 1,7 GHz) mit einer 30% Geschwindigkeitszunahme gegenüber dem Original Funktion

Was erwartet wurde, wenn Sie von 2 Lese + 2 Schreibvorgängen auf 1 Lese + 1 Schreibvorgang gehen.

Wenn Sie jedoch innerhalb von VLC arbeiten (die Funktion wird verwendet, um jedes über die Intel VAAPI-Schnittstelle decodierte Bild anzuzeigen), springt die CPU-Nutzung für dasselbe Video von 20% auf 32-34%

Ich bin verwirrt, warum das so wäre. und wie könnte das gelöst werden? Ich hatte ein entgegengesetztes Ergebnis erwartet. Beide Routinen verwenden SSE2 / 3, eine läuft schneller, verursacht aber eine erhöhte CPU-Auslastung

Danke

    
jyavenard 12.06.2014, 12:59
quelle

1 Antwort

2

Ok.

Ich habe herausgefunden, was los ist.

Während die neue Routine mit herkömmlichem Speicher viel schneller ist, ist es bei der Arbeit an Frames, die durch die Hardware-Dekodiermethode erzeugt werden, tatsächlich langsamer:

Dieses Intel White Paper erklärt die Dinge: Ссылка

Alle meine Benchmarks und Tests wurden mit traditionell zugewiesenem Speicher durchgeführt. Nicht von Uncacheable Speculative Write Combining (USWC)

zurück zum Zeichenbrett

    
jyavenard 15.06.2014, 02:51
quelle

Tags und Links