[dspman 0]

Коллеги!

 

В связи с расширением нашего направления по разработке математических библиотек срочно ищем молодых и умудренных опытом специалистов, способных разрабатывать ПО для DSP процессоров. Работа на зарубежных заказчиков, стабильная оплата. В данном случае речь идет о разработке ПО для нового процессора, который появится на рынке через год-два. Имя этого производителя известно на этом форуме каждому. Наши библиотеки будут поставляться в исходниках с этим процессором, наподобие dsplib для TI, только на несколько порядков круче. Отличная возможность для людей любящих математику и умеющих (хотящих научиться) писать код.

 

Обязанности:

 

*Разработка алгоритмов ЦОС - FIR/IIR, FFT/IFFT, операции с матрицами, векторная арифметика.

*Оптимизация алгоритмов ЦОС под параллельные DSP архитектуры (Texas Instruments, Analog Devices, Tensilica, Cadence, Elbrus, ARM NEON и др.)

*Поддержка разработанных библиотек

 

Требования:

*Высшее техническое образование.

*Владение программированием на языке С (строго)

*Алгоритмический склад ума.

*Желателен опыт работы с процессорами DSP, ARM.

*Обязательно желание работать в команде, четко выдерживать сроки выполнения задач.

*Крайне желательно понимание основ радиотехники

 

Условия:

 

*Работа с зарубежными и российскими HiTech компаниями.

*Бесплатное полноценное и очень вкусное питание, кофе, чай, плюшки

*Работа в дружной, слаженной и высококвалифицированной команде разработчиков

*Работа по ТК.

*Уровень заработной платы обсуждается по результатам собеседования и зависит от квалификации.

*Гибкий график, в некоторых случаях возможна работа из дома.

 

Пишите на [email protected] или в личку.

Дмитрий

 

 

 

[KA1 0]

Дмитрий, добрый день.

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

На Ваши вопросы готова ответить в личке или по почте [email protected]

[chefdesigner 0]

Дмитрий, добрый день.

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

На Ваши вопросы готова ответить в личке или по почте [email protected]

Животворящий кризис. Кадровики ищут работу.

[Max29 0]

Наши библиотеки будут поставляться в исходниках с этим процессором, наподобие dsplib для TI, только на несколько порядков круче.

 

круто!

Изменено 24 декабря, 2014 пользователем Max29

[jcxz 184]

Наши библиотеки будут поставляться в исходниках с этим процессором, наподобие dsplib для TI, только на несколько порядков круче.

Просьба уточнить - на несколько двоичных порядков или десятичных?

 

PS: Помнится в своё время (когда плотно писал на C5502), первое время использовал некоторые функции DSPLIB для него.

Потом как-то вчитался в их код и ужаснулся. Написаны они были до того топорно, что складывалось ощущение школьника (ну или человека поверхностно знающего данный CPU).

Когда потом я сам переписал к примеру функцию 32-битного БИХ на свою, получил ускорение примерно в 3 раза!

А судя по их коду, те кто их писал вообще не заморачивались оптимизацией. Скорее цель их была (если была какая-то цель) - простота кода.

К примеру: хотя C55xx ядро имеет два MAC-а, но почему-то команды работающие с двумя MAC-ами не использовались, а всегда использовался только один MAC.

Ну и прочие подобные вещи.

 

Так что превзойти их на неск. двоичных порядков наверное не проблема, если хоть немного изучить описание целевого DSP. ;)

[Max29 0]

PS: Помнится в своё время (когда плотно писал на C5502), первое время использовал некоторые функции DSPLIB для него.

Потом как-то вчитался в их код и ужаснулся. Написаны они были до того топорно, что складывалось ощущение школьника (ну или человека поверхностно знающего данный CPU).

Когда потом я сам переписал к примеру функцию 32-битного БИХ на свою, получил ускорение примерно в 3 раза!

А судя по их коду, те кто их писал вообще не заморачивались оптимизацией. Скорее цель их была (если была какая-то цель) - простота кода.

 

Сплошь и рядом. Авторами такого кода частенько оказываются не студенты, а ученые-теоретики. Математику вроде бы знают, а разбираться в особенностях архитектуры процессора лень либо нет времени.

 

[dspman 0]

Дмитрий, добрый день.

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

На Ваши вопросы готова ответить в личке или по почте [email protected]

 

Здравствуйте!

 

Наш опыт работы с кадровыми агентствами отрицателен, поэтому и не пользуемся.

 

 

 

Просьба уточнить - на несколько двоичных порядков или десятичных?

 

PS: Помнится в своё время (когда плотно писал на C5502), первое время использовал некоторые функции DSPLIB для него.

Потом как-то вчитался в их код и ужаснулся. Написаны они были до того топорно, что складывалось ощущение школьника (ну или человека поверхностно знающего данный CPU).

Когда потом я сам переписал к примеру функцию 32-битного БИХ на свою, получил ускорение примерно в 3 раза!

А судя по их коду, те кто их писал вообще не заморачивались оптимизацией. Скорее цель их была (если была какая-то цель) - простота кода.

К примеру: хотя C55xx ядро имеет два MAC-а, но почему-то команды работающие с двумя MAC-ами не использовались, а всегда использовался только один MAC.

Ну и прочие подобные вещи.

 

Так что превзойти их на неск. двоичных порядков наверное не проблема, если хоть немного изучить описание целевого DSP. ;)

 

 

Все вы правильно говорите, но наука и параллельные архитектуры ушли далеко вперед. Воспользоваться такими процессорами нет-то просто, а тем более реализовать высокопроизводительный математический алгоритм. Я не могу давать много информации, но вот некоторые названия алгоритмов из одного сделанного ранее проекта для процессора Tensilica BBE32 (32 MAC за такт), все функции параметризованные для матриц разного размера и точностей:

 

1. QR Decomposition

2. Rotation by Housholder Vectors

3. QR-based Back Substitution

4. Iterative Improvement for QR Solution

5. Cholesky Decomposition

6. Cholesky Forward Substitution

7. Cholesky Backward Substitution

8. Iterative Improvement for Cholesky Solution

9. Direct Matrix Inversion

10. Streaming Matrix Multiplies for Direct Matrix Inversion

11. Thin Singular Value Decomposition

12. CRC Calculation

13. Slicer Hard: QPSK, QAM16, QAM64

14. QAM Mapper: QPSK, QAM16, QAM64.

15. Universal Grey Coding/QAM Mapping

16. Soft Demapper for QPSK and QAM Constellations .

17. Bit Segmentation

18. Bit Packing

19. Convolution Encoder

20. Zadoff-Chu Sequence

21. FFT / IFFT, длины 2^n, n=4..15

22. FFT / IFFT, длины 12*2m*3 n*5p in range 12...1200

23. FFT / IFFT 1536

 

Сама по себе реализация такой пачки алгоритмов в целочисленной арифметике является делом нетривиальным..... А это все нужно оптимизировать под навороченную вычислительную архитектуру...

 

 

 

 

 

Сплошь и рядом. Авторами такого кода частенько оказываются не студенты, а ученые-теоретики. Математику вроде бы знают, а разбираться в особенностях архитектуры процессора лень либо нет времени.

 

Да, это катастрофа. Сейчас молодые инженеры даже не понимают, что это и есть настоящая инженерия, настоящая прикладная наука.. Что это интересно, перспективно и этим можно долго заниматься...

 

Ждем не дождемся, когда у наших хватит ума лицензировать такие ядра, сделать свой процессор и использовать в своих коммерческих или военных приложениях. Хуавей (точнее HiSilicon), к примеру, это сделал уже давно и нисколько не стесняется использовать эти ядра у себя.

 

 

 

--------------------

www.integrIT.ru

DSP development and VoIP

 

 

[Xenia 35]

Я не могу давать много информации, но вот некоторые названия алгоритмов из одного сделанного ранее проекта для процессора Tensilica BBE32 (32 MAC за такт), все функции параметризованные для матриц разного размера и точностей:

 

1. QR Decomposition

2. Rotation by Housholder Vectors

3. QR-based Back Substitution

4. Iterative Improvement for QR Solution

5. Cholesky Decomposition

...

21. FFT / IFFT, длины 2^n, n=4..15

22. FFT / IFFT, длины 12*2m*3 n*5p in range 12...1200

23. FFT / IFFT 1536

 

Сама по себе реализация такой пачки алгоритмов в целочисленной арифметике является делом нетривиальным..... А это все нужно оптимизировать под навороченную вычислительную архитектуру...

 

А что, для процессора Tensilica BBE32 вам удалось реализовать все это в целочисленной арифметике???

 

Простите, но мне сложно в это поверить. И хотя в интернете мне пока не удалось разыскать информацию, что собой представляет "Advanced Precision for matrix inversion and divide operations" у процессора BBE32, но чем бы это ни было, целочисленная арифметика никак не годится для функций 1-5, хотя и приемлема для 21-23.

 

Я лично сама когда-то возилась с функциями 1-5, пытаясь переходом на ассемблер ускорить их вычисление и увеличить точность вычисления малых собственных чисел действительной симметричной матрицы (это последовательное выполнение функций 2-1-3). Процессор то был не DSP, а обычный Pentium :), тем не менее, пришлось использовать разрядную сетку "long double" (80 бит), которую большинство современных C-компиляторов не поддерживают, хотя у архитектуры i86 такая возможность у FPU-сопроцессора есть. Впрочем, если пишешь на ассемблере, то это не важно.

 

Так вот мои "изыскания" :) показали, что для больших матриц (порядка выше 100) даже 80-битной разрядности float-операций не хватает для того, чтобы достичь приемлемой точности вычисления малых собственных чисел, если у той матрицы есть еще и большие. Фактически точность теряется уже на вычислении скалярных произведений векторов, когда малые слагаемые теряются, будучи прибавляемыми к накопленной большой сумме. Причем, теряются они не только на стадии QR decomposition, но уже даже на предшествующей стадии приведения матрицы к трехдиагональному виду с помощью Housholder rotation.

 

По этим причинам возможность вычисления всего этого в целочисленной арифметике кажется мне совершенно невероятной. Потому-то мне так хочется вас спросить - неужели правда, что вам это удалось сделать на целочисленной арифметике Tensilica BBE32?

[dspman 0]

А что, для процессора Tensilica BBE32 вам удалось реализовать все это в целочисленной арифметике???

 

Простите, но мне сложно в это поверить. И хотя в интернете мне пока не удалось разыскать информацию, что собой представляет "Advanced Precision for matrix inversion and divide operations" у процессора BBE32, но чем бы это ни было, целочисленная арифметика никак не годится для функций 1-5, хотя и приемлема для 21-23.

 

......

 

По этим причинам возможность вычисления всего этого в целочисленной арифметике кажется мне совершенно невероятной. Потому-то мне так хочется вас спросить - неужели правда, что вам это удалось сделать на целочисленной арифметике Tensilica BBE32?

 

Ксения, ну, во первых, это истинная правда :)

Перевод алгоритмов в целочисленную арифметику является отдельным "видом спорта". Это действительно сложно и этому надо учиться. Вся хитрость в том, чтобы понимать в каких частях алгоритма какие динамические диапазоны у величин. Это нужно для того, чтобы правильно использовать имеющиеся у вас типы данных - 16битные, 32 и т.д. Для этого надо понимать математику и уметь программировать. В принципе, сообразительные молодые ребята за год осваивают эту технику при правильном подходе.

 

Еще замечу, что все процессоры с плавающей точкой в своем основании являются целочисленными и работают, в конечном счете, на триггерах, у которых только 2 состояния 0 или 1. Плавучая арифметика в них эмулируется путем резервирования части битов под мантиссу и экспоненту.

 

Не сочтите меня за экстремиста, но, по сути, плавучка - это лишний промежуточный элемент между триггерами процессора и алгоритмом :)), который можно исключить.

 

Все наши работы закрыты NDA, а ядра поставляются большим компаниям за большие деньги, поэтому инфы мало. Если интересно, приезжайте, угостим кофе и покажем..

 

 

[Xenia 35]

Все наши работы закрыты NDA, а ядра поставляются большим компаниям за большие деньги, поэтому инфы мало. Если интересно, приезжайте, угостим кофе и покажем.

Женщина на корабле – к несчастью :). Но у меня и вопрос был поставлен в самом общем виде, не требущий раскрытия нау-хау.

 

Еще замечу, что все процессоры с плавающей точкой в своем основании являются целочисленными и работают, в конечном счете, на триггерах, у которых только 2 состояния 0 или 1. Плавучая арифметика в них эмулируется путем резервирования части битов под мантиссу и экспоненту.

Не сочтите меня за экстремиста, но, по сути, плавучка - это лишний промежуточный элемент между триггерами процессора и алгоритмом :)), который можно исключить.

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

 

Конечно же float-арифметика сводится в своей реализации к арифметике целочисленной, это понятно. Однако float-арифметика популярна именно потому, что она реализована аппаратно! Именно поэтому конвейерные/векторные DSP-операции столь эффективны. Но как только я стану реализовывать такую арифметике программно на целых числах, то у меня получится банальная эмуляция :). Та самая эмуляция, которая обычно бывает заложена в библиотеках тех МК, которые float-арифметику аппаратно не поддерживают. Считать на эмуляции можно, но ведь медленно же!

 

Именно из-за того, что программная эмуляция бывает чуть ли не на порядок медленее, чем аппаратная, у меня и возник к вам вопрос о побуждениях использовать целочисленную арифметику в алгоритмах, которые традиционно работают на арифметике плавающей, вследствие слишком большого разброса в порядках чисел. Для алгоритмов, типа FFT, целочисленная арифметика подходит хорошо, т.к. в этом алгоритме деления нет, а sin и cos могут быть загодя масштабированы в разрядной сетке целых чисел. Да и сами массивы данных, требующие FFT-преобразования, чаще всего являются целыми числами, поскольку их обычно получают от АЦП. Но когда объект матрица, а задача на сингулярное разложение, то тут и целочисленность исходной матрицы уже не в помощь, а опасность потерять значимость малых элементов встает в полный рост.

 

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

[dspman 0]

Женщина на корабле – к несчастью :). Но у меня и вопрос был поставлен в самом общем виде, не требущий раскрытия нау-хау.

 

У нас представители этого прекрасного вида на корабле уже давно, плаваем :)

 

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

 

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

 

Конечно же float-арифметика сводится в своей реализации к арифметике целочисленной, это понятно. Однако float-арифметика популярна именно потому, что она реализована аппаратно! Именно поэтому конвейерные/векторные DSP-операции столь эффективны. Но как только я стану реализовывать такую арифметике программно на целых числах, то у меня получится банальная эмуляция :). Та самая эмуляция, которая обычно бывает заложена в библиотеках тех МК, которые float-арифметику аппаратно не поддерживают. Считать на эмуляции можно, но ведь медленно же!

 

Все верно, но энергопотребление процессоров с плавучкой и фиксированной точкой не в пользу первого. Много задач, в которых энергопотребление не важно, там где рядом есть мощный источник питания и хороший теплоотвод. Но в системах с батарейкой надо экономить на всем, поэтому там применяются процессоры целочисленные. У Тенсилики есть контроллер, который обрабатывает клавиатуру, так он умудряется поспать, пока пользователь палец переносит от одной кнопки к другой....

 

 

Именно из-за того, что программная эмуляция бывает чуть ли не на порядок медленее, чем аппаратная, у меня и возник к вам вопрос о побуждениях использовать целочисленную арифметику в алгоритмах, которые традиционно работают на арифметике плавающей, вследствие слишком большого разброса в порядках чисел. Для алгоритмов, типа FFT, целочисленная арифметика подходит хорошо, т.к. в этом алгоритме деления нет, а sin и cos могут быть загодя масштабированы в разрядной сетке целых чисел. Да и сами массивы данных, требующие FFT-преобразования, чаще всего являются целыми числами, покольку их обычно получают от АЦП. Но когда объект матрица, а задача на сингулярное разложение, то тут и целочисленность исходной матрицы уже не в помощь, а опасность потерять значимость малых элементов встает в полный рост.

 

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

 

Мы говорим не об эмуляции арифметики с плавающей точкой, а замене операций с плавающей точкой на операции с фиксированной. Т.е., очень грубо говоря, количество умножений и сложений остается в обоих случаях одинаково.

 

А по поводу причины все просто - наш заказчик идет за рынком, делает для него ядра, а мы идем за ним и подгоняем математику :)