Программирование TI DSP - достаточно ли быстр C или мне нужен ассемблер? - PullRequest
7 голосов
/ 21 сентября 2009

Я собираюсь написать несколько программ для обработки изображений для платформы Texas Instruments DaVinci. Существуют инструменты, подходящие для программирования на языке Си, но мне интересно, действительно ли возможно в полной мере использовать процессор DSP, не прибегая к языку ассемблера. Знаете ли вы о каких-либо сравнениях скорости между программами, написанными на C и на ассемблере на этой платформе DSP?

Ответы [ 8 ]

11 голосов
/ 21 сентября 2009

Я использовал некоторые другие DSP TI, и C обычно был в порядке. Обычный подход состоит в том, чтобы начать с написания всего на C, а затем профилировать код, чтобы увидеть, нужно ли что-то оптимизировать вручную.

Вы также можете часто выполнять оптимизацию в C, корректируя код C до тех пор, пока не получите требуемый вывод сборки. Важно знать, как работает DSP и какие способы работы быстрее или медленнее.

10 голосов
/ 06 ноября 2009

Компилятор TI для C64x / C64x + DSP на OMAP3 включает поддержку того, что TI называет «внутренними» вызовами функций. На самом деле это не вызовы функций, это просто способ сообщить компилятору, какой код операции сборки использовать для операции, которая не может быть прямо выражена в C. Это особенно полезно для использования кодов операций SIMD в C64x / C64x + DSP из C.

Примером может быть:

A = _add2 (B, C);

Эта инструкция SIMD складывает младшие / старшие 16 битов B и C вместе и сохраняет результаты в младших / старших 16 битах A. Вы не можете выразить это в обычном C, но вы можете сделать это с помощью встроенного C-коды.

Я использовал встроенный C, чтобы максимально приблизиться к тому, что вы могли бы сделать с полнофункциональным языком ассемблера (в пределах 5-10%). Это особенно полезно для видео функций, таких как фильтрация и компенсация движения (_dotpsu4!).

Я обычно компилирую с ключом -al и смотрю на конвейер, чтобы попытаться определить, какие функциональные блоки перегружены, а затем смотрю на свои внутренние компоненты, чтобы посмотреть, смогу ли я перебалансировать цикл (если я использую слишком много блоков S, Я мог бы посмотреть, смогу ли я изменить код операции, чтобы использовать единицу M).

Также полезно помнить, что C64x DSP имеет 64 регистра, поэтому загрузите локальные переменные и никогда назначьте вывод команды обратно в ту же переменную - это отрицательно скажется на способности компилятора правильно выполнять конвейеризацию.

7 голосов
/ 21 сентября 2009

Обычно C - хорошее место для начала. Вы можете быстро получить общую структуру и алгоритмы и написать большую часть данных, которые перемещают данные между реальной математикой. Как только это будет сделано, и вы будете довольны тем, что ваши структуры данных верны, вы можете посмотреть в профилировщике и выяснить, какие подпрограммы нужно сжать вручную.

6 голосов
/ 21 сентября 2009

C-Compiler (насколько я тестировал) не в полной мере использует архитектуру.

Но с этим можно сойти, потому что DSP может быть достаточно быстрым для операций, которые вам нужно сделать.

Итак, все сводится к тестированию и профилированию вашего кода, чтобы увидеть части, которые должны быть ускорены, чтобы система заработала.

2 голосов
/ 22 марта 2011

простое сравнение скорости ничего не значит. Определенно с, если удобнее, чем ассемблер. Вы должны измерить стоимость времени вашей системы, если код c удовлетворяет вашим требованиям к скорости, вам не нужно использовать ассемблер. Если скорость недостаточна, вы можете профилировать свой код, узнать наиболее трудоемкий исходный код, такой как код цикла, а затем оптимизировать его!

2 голосов
/ 21 сентября 2009

Зависит от компилятора C и вашего определения «достаточно быстро». Стандартные компиляторы C часто пытаются эффективно использовать специальное аппаратное обеспечение DSP, например:

  • Несколько банков памяти, которые могут быть доступ параллельно
  • Типы данных с фиксированной точкой
  • Круговые буферы
1 голос
/ 21 сентября 2009

Я бы придерживался C, пока не узнаю, что есть горячая точка, которая может выиграть от кодирования сборки. Это метод «профилирования», который я использую. Вы можете быть удивлены, что есть способы ускорить код, которые не являются горячими точками, а скорее промежуточными вызовами функций, которые могут быть удалены.

0 голосов
/ 16 апреля 2019

Компиляция с использованием оптимизации -O3. Это очень мощный.
Если он недостаточно хорош, вы можете дополнительно оптимизировать сгенерированный ассемблерный код по своему вкусу, вместо того чтобы кодировать все самостоятельно в ASM с нуля.

...