TI DSP-Programmierung - ist C schnell genug oder brauche ich einen Assembler?

Question

Ich werde einige Bildverarbeitungsprogramme für die DaVinci-Plattform von Texas Instruments schreiben. Es gibt Werkzeuge, die für die Programmierung in der Sprache C geeignet sind, aber ich frage mich, ob es wirklich möglich ist, den DSP-Prozessor voll auszunutzen, ohne auf eine Assemblersprache zurückgreifen zu müssen. Kennen Sie Geschwindigkeitsvergleiche zwischen C- und Assembler-Programmen auf dieser DSP-Plattform?

Answer 1

Der C-Compiler (soweit ich getestet habe) nutzt die Architektur nicht voll aus.

Aber Sie können damit durchkommen, weil die DSP schnell genug für die Operationen sein kann, die Sie tun müssen.

Es kommt also darauf an, Ihren Code zu testen und zu profilieren, um die Teile zu sehen, die beschleunigt werden müssen, damit das System funktioniert.

Answer 2

Ich habe einige andere TI DSPs verwendet und C war in der Regel in Ordnung. Der übliche Ansatz besteht darin, zunächst alles in C zu schreiben und dann den Code zu profilieren, um zu sehen, ob etwas von Hand optimiert werden muss.

Sie können die Optimierung oft auch in C vornehmen, indem Sie den C-Code anpassen, bis Sie die gewünschte Assembly-Ausgabe erhalten. Es ist wichtig zu wissen, wie der DSP funktioniert und welche Arbeitsweisen schneller oder langsamer sind.

Answer 3

Hängt vom C-Compiler und Ihrer Definition von "schnell genug" ab. Standard C Compiler kämpfen oft effizienter Einsatz spezieller DSP-Hardware zu machen, wie zum Beispiel:

• Mehrere Speicherbänke, die parallel
• Festpunktdatentypen
• Rundpuffer zugegriffen werden kann

Answer 4

Normalerweise ist C ein guter Anfang. Sie können das gesamte Framework und die Algorithmen schnell ausschütteln und die meisten Installationen schreiben, die die Daten zwischen der echten Mathematik bewegen. Sobald dies geschehen ist und Sie sich darüber freuen, dass Ihre Datenstrukturen korrekt sind, können Sie in einem Profiler nachschauen, welche Routinen von Hand gequetscht werden müssen.

Answer 5

Ich würde bei C bleiben, bis ich weiß, dass es einen Hotspot gibt, der von der Assemblercodierung profitieren könnte. This is the "profiling" method I use. Sie könnten überrascht sein, dass es Möglichkeiten gibt, den Code zu beschleunigen, bei denen es sich nicht um Hotspots handelt, sondern um Zwischenfunktionen, die entfernt werden können.

Answer 6

Der TI-Compiler für den C64x/C64x + DSP auf dem OMAP3 bietet Unterstützung für das, was TI "intrinsische" Funktionsaufrufe nennt. Sie sind nicht wirklich Funktionsaufrufe, sie sind nur eine Möglichkeit, dem Compiler mitzuteilen, welcher Assembly-Opcode für eine Operation verwendet werden soll, die in C nicht direkt ausgedrückt werden kann. Er ist besonders nützlich, um die SIMD-Opcodes im C64x/C64x + DSP zu nutzen C.

Ein Beispiel könnte sein:

A = _add2 (B, C);

Diese SIMD-Anweisung addiert die niedrigen/hohen 16 Bits von B und C zusammen und speichert die Ergebnisse in den niedrigen/hohen 16 Bits von A. Sie können dies nicht in regulärem C ausdrücken, aber Sie können es mit dem tun intrinsische C-Opcodes.

Ich habe intrinsische C verwendet, um sehr nahe an das heranzukommen, was man mit einer vollwertigen Assemblersprache (innerhalb von 5-10%) machen könnte. Dies ist besonders nützlich für Videofunktionen wie Filterung und Bewegungskompensation (_dotpsu4!).

Normalerweise kompiliere ich mit dem -al-Schalter und schaue mir die Pipeline an, um herauszufinden, welche Funktionseinheiten überlastet sind, und schaue dann auf meine Eigenheiten, um zu sehen, ob ich die Schleife neu ausbalancieren kann (wenn ich zu viele S-Einheiten verwende) , Könnte ich sehen, ob ich den Opcode ändern könnte, um eine M-Einheit zu verwenden).

Auch ist es hilfreich, sich daran zu erinnern, dass der C64x-DSP 64 Register hat, so die lokalen Variablen zu laden und nie die Ausgabe eines wieder in die gleiche Variable Befehl zuweisen - es sich negativ auf die Compiler beeinflussen werden Fähigkeit, richtig zu pipeline.

Answer 7

der einfache Vergleich der Geschwindigkeit bedeutet nichts. Definitiv c wenn praktischer als Assembler. Sie müssen die Kosten der Zeit Ihres Systems messen, wenn der c-Code Ihre Geschwindigkeitsbegrenzung erfüllt, müssen Sie Assembler nicht verwenden. Wenn die Geschwindigkeit nicht ausreicht, können Sie Ihren Code profilieren, den zeitaufwendigsten Quellcode wie Loop-Code herausfinden und ihn dann optimieren!