[vid435 0]

Имеется референсный фикс пойнтовый код. Необходимо оптимизировать по скорости коррелятор, FIR дециматор, Витерби декодер, декодер Рида Соломона, АРУ и др. Объем кода небольшой, корректора канала и обращения матриц нет. Код структурирован, интринсики и другие базовые операции вынесены в отдельные файлы, имеется тестовая среда.

Часть функций достаточно будет оптимизировать на C или использовать dsplib, но часть видимо придется переписать на asm.

Необходимо сохранить читаемость кода, возможность сборки под MSVC и без оптимизации под 54XX. Среда разработки CCS3.3.

iliya.voronov(a)rfdsp.ru

7(916)683-5103

Илья

[VasiaMVR 0]

Удаленка возможна?

Сроки, стоимость?

 

использовать dsplib, но часть видимо придется переписать на asm

и

возможность сборки под MSVC и без оптимизации под 54XX

подразумевает под собой два вида исходников (двойная работа) оптимальный код 54XX с использованим dsplib, специфичных команд и блоков (тот-же CSSU для Viterbi) и код на С который должен в точности повторять логику первого?

 

Каким образом будет приниматься работа в плане оптимизации кода?

 

 

[jcxz 184]

Необходимо сохранить читаемость кода, возможность сборки под MSVC и без оптимизации под 54XX. Среда разработки CCS3.3.

Интересно - как это стыкуется с переписыванием на asm???

"Оптимизировать на си".... В те времена когда я плотно писал для 5502, "код на си" - это уже по определению было очень далеко от оптимальности и говорить о какой-то оптимизации на си смысла не было -

аналогичная функция, написанная на асм бывало раз в 10 быстрее работала и никакие ключи оптимизации не спасали.

Одно только использованием инструкций условных переходов в циклах чего стоило :)

Хотя конечно может за это время в CGT для CCS3.3 что-то кардинально изменилось.

 

И зачем кстати - для 54XX? Он же давно уже не актуален. Или у вас имеется некоторое кол-во изделий на 54XX которые надо доработать?

Если нет - используйте лучше 55XX. Он во многом совместим по системе команд как я понимаю. И он сейчас ЖИВ.

 

DSPLIB кстати там - это очень далеко от оптимальности. Некоторые функции из неё мне в своё время удавалось переписать с ускорением до 3 раз.

Написана она там по-моему школьниками.

 

Каким образом будет приниматься работа в плане оптимизации кода?

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

[vid435 0]

Удаленка возможна и даже приветствуется, но надо встречаться чтобы передать железки, хотя если у исполнителя есть любая плата с 5416 и эмулятор то это не нужно. Хочется получить результат через месяц, хотя реальной работы для того кто этим занимается дней на 7 - 10. Стоимость имеет смысл обсуждать лично.

 

Неоптимизированный код под 54 и код для MSVC это не "двойной код", а один и тот же код, в которым базовые операции типа ADD, MPY, MAC (все это помещается в один h-файл) определены либо через интринсики 54, либо битэкзектные их реализации как функции на стандартном С.

 

Наверно есть три варианта:

1. В случае простых алгоритмов (FIR, свертка, векторные операции) оптимальный C-шный код пишется легко и почти не хуже asm. И это уже во многом сделано. Там правда есть специфическая проблема 54 то что в C нет 40-битных чисел и результаты MAC должен укладываться в 32 бита.

2. Если алгоритмы сложнее (например БПФ) это уже сделать сложнее, и dsplib тут вполне подходит. Хотя я его тоже его не люблю.

3. А вот как оптимально написать Витерби на С я не знаю (может кто-то знает), действительно C-шный код раз в 10 медленнее asm а в нем и тратится большая часть MIPSов. И тут действительно будет два кода - один оптимальный на asm, второй битэкзектный с ним на С неоптимальный 54 и MSVC. Но это и есть основная задача.

 

Надо вписаться в 90 MIPS (имеющиеся 100 МГц процессора минус 10% потери на прерывания, и прочие служебные функции). Для данного модема это вполне достаточно.

Конечно у 55 лучше и архитектура процессора и компилятор. Но нужен именно 54XX.

[VasiaMVR 0]

Не хотел отвечать, но наболело. Вот знал, что если в теме написано слово простой не стоит туда заходить в принципе.

 

Сделать так что-бы как-то заработало это 20% времени(а если в инете найти готовые исходники и сильно не вникать в суть, а лишь правильно все соединить ещё меньше), выдавить максимальную скорость это 80% времени (вникнуть досконально, продумать порядок выполнения действий, проработать несколько вариантов выбрать лучший, иногда вообще пересмотреть весь алгоритм с 0). Но все кто не сильно в теме считают, что там нечего делать, все же работает, надо только слегка оптимизировать и всё.

 

И вообще дорабатывать за кем-то дело неблагодарное, каждый раз жалел, что взялся.

 

Хочется получить результат через месяц, хотя реальной работы для того кто этим занимается дней на 7 - 10. Стоимость имеет смысл обсуждать лично.

За 7-10 дней может и можно, только это по 10(может и больше) часов в сутки и без выходных отличного специалиста. Кроме того, везде за скорость нужно дополнительно доплачивать, иногда до 100%, а в разработке наоборот считается, что если человек напрягся и сделал в 2 раза быстрее, то ему можно раза в 2 меньше заплатить.

А так, если реально смотреть 3-7дней вы будете искать исполнителя .

 

Под последнее слово фо фразе «…. Соломона, АРУ и др» можно много чего накидать.

Если хотите дешево. Напишите четкое Т.З. Где пропишите без «и др.» все блоки которые нужно оптимизировать, их текущую скорость и что хотелось-бы, выложите исходники. Может там действительно не так много, работы.

А если нужно дешевле сделайте сами, будут вопросы пишите в соответствующие темы, народ вам поможет. Заодно узнаете насколько просто (щас в меня помидоры полетят :)).

Без этого, только человек не в теме ломанется, поскольку без четкого описания апетит заказчика растет во время работы :).

 

Неоптимизированный код под 54 и код для MSVC это не "двойной код", а один и тот же код, в которым базовые операции типа ADD, MPY, MAC (все это помещается в один h-файл) определены либо через интринсики 54, либо битэкзектные их реализации как функции на стандартном С.

т. е. написать интерпретатор команд DSP проца.

 

А вот как оптимально написать Витерби на С я не знаю

Витерби сам по себе простой алгоритм, но требует много вычислений для этого в этом проце есть CSSU. Да и ещё максиамльная скорость и переносимость кода это противоричивые параметры. Хотите скорость будет ограничена переносимость и наоборот.

 

Надо вписаться в 90 MIPS (имеющиеся 100 МГц процессора минус 10% потери на прерывания, и прочие служебные функции). Для данного модема это вполне достаточно.

Конечно у 55 лучше и архитектура процессора и компилятор. Но нужен именно 54XX.

90 MIPS ни о чем не говорит без привязки к скорости передачи данных и необходимым числом операций требуемым для каждого алгоритма. Вот если-бы вы сказали, что при затратах в 90 MIPS скорость обработки N кбит/c, а хотелось-бы 2*N это было понятнее.

 

Удачи в поиске. (Ищите толкового студента, заодно поучиться, только сроки увеличьте)

[jcxz 184]

Не хотел отвечать, но наболело. Вот знал, что если в теме написано слово простой не стоит туда заходить в принципе.

...

Согласен со всем на 100%

 

т. е. написать интерпретатор команд DSP проца.

Человек хочет симулятор 54XX. Непонятно - чем его не устраивает симулятор в CCS???

Да ещё и за неделю, бонусом к остальной работе. А ведь в CCS его думаю ГОРАЗДО дольше писали.

 

Удачи в поиске. (Ищите толкового студента, заодно поучиться, только сроки увеличьте)

... раз в ..дцать

 

PS: А ведь ещё, как я понял, речь идёт о реальной готовой железке. А к ней ведь нужна работа с периферией, ввод/вывод, а если оно там типа уже есть, то кто-ж его знает как оно там реализовано и не понадобится-ли всё это переписывать чтоб скорость получить? И как эта периферия подключена и не окажется-ли что она так подключена что работа с ней съедает львиную долю ресурсов CPU? (сталкивался и с таким)....

В начальном сообщении говорилось только про код, а здесь уже выясняется, что есть потери на прерывания и "прочие служебные функции"....

 

1. В случае простых алгоритмов (FIR, свертка, векторные операции) оптимальный C-шный код пишется легко и почти не хуже asm. И это уже во многом сделано. Там правда есть специфическая проблема 54 то что в C нет 40-битных чисел и результаты MAC должен укладываться в 32 бита.

Хммм.... Неужто всё-ж таки допилили CGTools для 54/55 ядер?

При компиляции си-шных циклов, компилятор теперь использует RPTB/RPTBLOCAL ?

Лет этак 6 назад никакими ключами компиляции этого добиться не удавалось. А без этого ни о каких си в аспекте оптимальности, говорить не приходится.

Да и в остальном си по сравнению с асм... кхе-кхе...

Или может вы асм для этого ядра не знаете? Так так и скажите :rolleyes:

 

Хотя впрочем для 54xx - я тоже не знаю. Только для 55xx.... знал когда-то :)

[ASN 0]

jcxz

IMHO, С-компилятор даже для С55 не развивается уже давно. А для С54 и подавно.

vid435

Сильно сомневаюсь, что С-ный код на С54 будет сильно оптимальным по сравнению с ассемблерным. Хотя бы из-за особенностей передачи параметров в процедуры именно для С54.

С Витерби тоже не всё так просто. Сильно зависит от реализации (потоковый или блочный). На С для С54 сделать реализацию несильно (а не в разы, а может быть и на порядок) уступающую ассемблерному коду нельзя.

Код Рида-Соломона для С54 тоже нетривиальная задача, если надо получить производительность.

Без описания системы, на которой планируется сделать, IMHO, сложновато будет найти адекватного исполнителя за 7-10 дней.

Потому, что АРУ - это тоже важно, и про прерывания тоже забывать при написании кода не стоит. Не про потери на прерывания, а про потери самого события. Код должен писаться с учётом этого.

 

[vid435 0]

исполнитель найден, тему можно закрывать