[an error occurred while processing this directive]
К вопросу С vs. Assembler
(«Телесистемы»: Конференция «Цифровые сигнальные процессоры (DSP) и их применение»)

миниатюрный аудио-видеорекордер mAVR

Отправлено Миша 28 октября 2002 г. 07:50
В ответ на: Ну вы блин даете... DSP сделаны как я понимаю не для того, чтобы гробить их производительность писанием на C. За исключением (и то в 10% случаев) VLIW. отправлено SM 25 октября 2002 г. 01:02

Плотно работаю с 64хх. Пишу на С++. Хочу сказать следующее:

1) Если делать по уму, то надо тщательно провести профилировку проекта - где, что и как растрачивается.
2) Как правило, чуть ли не 90% ресурсов тратится на некоторый "базисный" набор операций, например: свертки, перемножение матрицы на вектор и т.д. Во многом тип и набор этих операций существенно определятся задачей.
3) Довольно приличный набор этих операций (функций) реализован в библиотеках типа DSPLIB. Есть исходники в трех вариантах: параллельный ассемблер, линейный ассемблер, С.
4) Мое мнение, что во многих случаях применение подобных вещей (либо готовых, либо написанных самим (м.б. функция какого-нибудь "нестандратного" фильтра - это просто условный пример)) + использование языка типа С/С++ дает ту-же самую производительность, что и писанина на чистом асме. Насчет эффективности разработки (время и дальнейшее сопровождение), я думаю, комментарии излишни.

5) Хочу сказать конкретно про С64хх. Для своих целей (и по работе непосредственно и для удовлетворения профессионального любопытсва) пробовал делать следующие эксперименты:
брал какую-нибудь функцию (например, свертка), смотрел ее производительность в техасовской либе и писал то-же самое на С с использованием прагм и интринсиков для С6000. Результат по эффективности один и тот-же. Детали я сейчас не помню, так как это относительно давно было, но вывод я для себя сделал такой - для С64хх С/C++ компилер очень даже неплохая штука. + Возможно здесь еще его архитектура роль играет - С62хх просто отстой по сравнению с ним.
Я думаю, что в техасовской либе эти функции не самым медленным образом реализованы (мягко говоря), так что выводы делайте сами.

6) Еще советую почитать рекомендации самого техаса - по поводу на чем писать С/лин. ассемблер/ паралл. ассемблер.

7) по поводу других сигнальников (и не только) и асма/C.
- работал с ADSP218x очень много и на С и на асме. Считаю, что С здесь в плане эффективности - ПОЛНЫЙ ОТСТОЙ, впрочем сам Аналог об этом пишет. Писал на нем только "обвязку" верхнего уровня исходя из принципа - потеряю 2-3-5% суммарной производительности, но напишу это все быстрее в 2-3 раза и все более понятно будет для других людей.
- писал плотно и на асме и на С для AVR. От его С просто тащусь Сейчас этим не занимаюсь, но мой друг пишет для AVR на С++ - тащится конкретно, хотя задачи у него очень критичные по времени.

8) Еще раз по поводу C62xx vs. C64xx. До того, как начал работать с 64хх анализировал это и приходил к выводу, что 64хх лучше, а 62хх хуже :))
Когда реально проверил один очень сложный проект на производительность на 62хх и 64хх понял, что С62хх - просто отстой.
Если интересно - можно посмотреть производительность (опять же от Техаса) для алгоритмов типа G.723, G.729 и .т.п. для С62хх - сразу все эти МИПСы сдуваются и вообще непонятно, зачем этот С62хх сделали.

Любопытно, что есть одна статья от Аналога, где он сравнивает 67хх и какой-то свой ШАРК. Там Аналог в частности дает очень грамотное объяснение : что в 67хх (62хх) плохо. Понятно, что эта статья написана заинтересованной стороной, но внимательно ее прочитав со многим соглашаешься. Так вот, если проанализировать
а) архитектуру С62хх
б) архитектуру С64хх
в) эту статью от Аналога
то впечатление, что Техас просто сделал "работу над ошибками".
Насчет компилеров С для 62хх - вполне возможно (это моя гипотеза), что Техас на них просто болт положит, а весь упор на С64хх сделат.

Составить ответ  |||  Конференция  |||  Архив

Ответы


Отправка ответа

Имя (обязательно): 
Пароль: 
E-mail: 

Тема (обязательно):
Сообщение:

Ссылка на URL: 
Название ссылки: 

URL изображения: 


Перейти к списку ответов  |||  Конференция  |||  Архив  |||  Главная страница  |||  Содержание  |||  Без кадра

E-mail: info@telesys.ru