Ответ: («Телесистемы»: Конференция «Цифровые сигнальные процессоры (DSP) и их применение»)

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

Отправлено st256 31 октября 2006 г. 12:54
В ответ на: Зря Вы 67-е в один ряд с Тигерами поставили - абсолютно разные процессоры и друг другу не соответствующие ни по возможностям, ни по цене. 67-е можно с Шарками сравнивать. А насчет фиксед пойнт... (+) отправлено <font color=gray>homekvn</font> 31 октября 2006 г. 12:21

=== Вот, например, мне сейчас надо сделать КИХ-фильтрацию 14-ти аудиоканалов. Все фильтры длинные (за исключением пары фильтров, длина которых 256). Естественно, приходится делать кусочную свертку в частотной области. Делай я это в фиксед пойнт - получил бы шумов много на прямом и обратном БПФ (либо надо было бы делать в 32-разрядах, что не очень эффективно для недорогих 16разрядных процессоров; а кроме того, встала бы та же проблема большого динамического диапазона, так что с нормировками сигналов геморрой бы возник).

Если не считать того, что я не знаю, что такое "кусочная свертка в частотной области", то Вы меня не убедили. Особенно, с учетом того, что с аудио я работал 2 года. Естественно, фильтрация в частотной области по-быстрее идет, но 32-разряда мне кажется, все-таки хватит и для этого случая даже с учетом нормировки.
Кроме того, как-то мне без знания задачи кажется странным применение слишком длинных КИХ-ов. Я всегда обходился без них. Ес-но, приходилось немного шевелить извилинами...

=== Так что подождите хоронить флоатинг-пойнт процы - они вечны. :-)

Боже упаси! Просто я с ними не работал никогда...

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

Ответы

Ответ (+) — homekvn (31.10.2006 13:25 212.185.161.237, 3150 байт)
- Ответ: — st256 (31.10.2006 14:07 217.151.231.218, 733 байт)
  - Ответ (+) — homekvn (31.10.2006 15:25 212.185.161.237, 1930 байт)
    - Ответ. Окончательный и обсуждению не подлежащий. — st256 (31.10.2006 16:16 217.151.231.218, 1062 байт)
      - Ответ (ну я не настаиваю на окончательности моего ответа и на его необсуждаемости) — homekvn   (31.10.2006 16:47 212.185.161.237, 1778 байт)
        
        А еще по поводу fixed и floating... (+) — ASergej_R19   (31.10.2006 17:24 80.250.160.170, 326 байт)
        
        Да я и это не оспаривал (+) — homekvn   (31.10.2006 17:45 212.185.161.237, 1479 байт)
        
        Вот пример не в отрыве... (+) — ASergej_R19   (31.10.2006 18:16 80.250.160.170, 67 байт)
        
        Ответ (+) — homekvn   (31.10.2006 18:26 212.185.161.237, 258 байт)
        
        Ответ — ASergej_R19   (31.10.2006 18:46 80.250.160.170, 330 байт)
        
        Ответ (+) — homekvn   (31.10.2006 19:14 212.185.161.237, 2314 байт)
        
        Я же Вам писал по поводу Блекфина... (+) — ASergej_R19   (31.10.2006 19:45 80.250.160.170, 348 байт)
        
        Ладно, убедили, что Блекфин с этой задачей справится не хуже Шарка (включая то, что Шарк работает на частоте в 2 раза ниже). А с точностью - сомневаюсь, что все будет лучше. — homekvn   (31.10.2006 19:59 212.185.161.237, пустое)
        
        С точностью - как уже писалось, fixed ненамного лучше float'а... (+) — ASergej_R19   (31.10.2006 20:05 80.250.160.170, 174 байт)
        
        А то, что еще можно сделать в параллель, так Шарк может до 5 инструкций в параллеле делать. Следовательно в SIMD-режиме, аж до 10-ти. (+) — homekvn   (31.10.2006 20:03 212.185.161.237, 50 байт)
        
        Ну так тут получается порядка 10 тактов на бабочку 16-бит, и до 18-20 если 31-бит fixed... не знаю сколько Шарк... (-) — ASergej_R19   (31.10.2006 20:12 80.250.160.170, пустое)
        
        Ну раздразнили Вы меня! (+) — homekvn   (31.10.2006 20:19 212.185.161.237, 500 байт)
        
        Ну хорошо... Пускай Блекфину на это потребуется в пересчете на Вашу тактовую частоту в 2 раза больше времени (31 bit fixed)... И что этим было доказано? :-) (+) — ASergej_R19   (31.10.2006 20:36 80.250.160.170, 524 байт)
        
        Не, не "пусть" (+) — homekvn   (31.10.2006 20:47 212.185.161.237, 542 байт)
        
        Эээ... (+) — ASergej_R19   (31.10.2006 20:59 80.250.160.170, 683 байт)
        
        Пардон - читать - в каждом такте 2 32-х разрядных значения... (-) — ASergej_R19   (31.10.2006 19:47 80.250.160.170, пустое)
        
        А вот еще последний гвоздь (+) — homekvn   (31.10.2006 19:27 212.185.161.237, 773 байт)
        
        Вообще-то я ничего не сдвигаю - просто складываю раздельно сумму и число отсчетов... (+) — ASergej_R19   (31.10.2006 19:40 80.250.160.170, 165 байт)
        
        В том примере, что я привел, превысит не 16-ти разрядную, а 32-разрядную, если суммировать влоб. Ведь Вы суммировать-то квадраты будете... — homekvn   (31.10.2006 19:43 212.185.161.237, пустое)
        
        Выйдут за 32 - конечно... Просто думал одно написал другое - там просто бит переноса учитывать... Или как BH писал... (-) — ASergej_R19   (31.10.2006 19:50 80.250.160.170, пустое)
        
        Так в Блэкфине результат (40bit) в A0 и A1можно накапливать..)) — quark   (31.10.2006 19:53 62.140.241.223, пустое)
        
        Складывать с ними муторно - надо писать в A0, а потом его уже с A1, потом все раздельно выгружать в регистры... (+) — ASergej_R19   (31.10.2006 19:57 80.250.160.170, 112 байт)
        
        Да, правильно. Этого я не принял в расчет. — homekvn   (31.10.2006 19:56 212.185.161.237, пустое)
        
        Но вот если будем суммировать больше 256 чисел, то могут быть проблемы. Переполнится A1 будучи 40 битным. — homekvn   (31.10.2006 20:00 212.185.161.237, пустое)
        
        Или Вы квадраты к 16 битам приводить будете? — homekvn   (31.10.2006 19:44 212.185.161.237, пустое)
        
        Уж не знаю как там у блэкфина, но делить каждое число перед возведением в квадрат - это какое-то особенный шик, больше напоминающий извращение. Вот Вам навскидку метОд. Отдельно суммируете старшие 16-ти разрядные чапсти квадратов, отдельно младшие. Потом суммы сшиваете и результат делите. Или сначала делите, потом сшиваете, пофигу. И гвоздь Ваш совсем ржавый в результате получился. — -=ВН=-   (31.10.2006 19:36 193.125.71.140, пустое)
        
        Можно эту операцию расписать для того примера, что я привел ранее (+) — homekvn   (31.10.2006 19:53 212.185.161.237, 552 байт)
        
        А я Вам ответил, что точный результат получается за время ~2*N. И если нужно деление (считается средний квадрат), то делится означенный точный результат, а вовсе не каждый операнд. И годится это дело для любого вектора, хорошего ли, плохого ли. 2*N гораздо хуже, чем N, гораздо, но много лучше деления каждого отсчета, много лучше. — -=ВН=-   (31.10.2006 20:02 193.125.71.140, пустое)
        
        Просто все это справедливо, если мы имеем 40-битный аккумулятор. Без него суммирование должно дать переполнение. А с 40-битным аккумулятором проблема может возникнуть, если длина вектора больше 256 и все числа равны по модулю (или сравнимы по модулю с) 16535. — homekvn   (31.10.2006 20:11 212.185.161.237, пустое)
        
        Ну уж из-за такой ерунды спор... В высокоинтеллектуальном методе, мной предложенном, суммируются 16-ти разрядные числа. Много. Для этого в громадном большинстве случаев хватит 32-х р. аккумулятора. И 1 раз сшиваются 2 32-х разрядных числа. Что естт пустяк. — -=ВН=-   (31.10.2006 20:25 193.125.71.140, пустое)
        
        Либо я в Вашем методе чего-то не догнал, либо Вы чего-то в моем вопросе недопоняли (+) — homekvn   (31.10.2006 20:35 212.185.161.237, 492 байт)
        
        Правильно поняли. Но последняя опреация делается 1 раз на весь большой массив. И для этого 1 раза рарядность аккумулятроа никак меня не волнует. Пусть он даже 1 разрядный будет. Уж как нибудь совладаю с непосильной задачей сложения 2 чисел. Важны потери времени. Они в этом случае небольшие. По крайней мере намного меньше, чем в случае деления каждого операнда. Что тут непонятного? — -=ВН=-   (31.10.2006 20:44 193.125.71.140, пустое)
        
        А никто и не говорил, что у Блекфина производительность больше чем у Шарка... (+) — ASergej_R19   (31.10.2006 20:02 80.250.160.170, 222 байт)
        
        А если использовать оба аккумулятора A0 и A1, то посчитает за время вдвое меньшее.. — quark   (31.10.2006 20:06 62.140.241.223, пустое)
        
        Вряд ли получится. Вот ASergej_R19 привел пример кода который навряд ли можно уменьшить. Там оба аккумулятора задействованы --> — homekvn   (31.10.2006 20:13 212.185.161.237, пустое, ссылка)
        
        Он там малость ошибся (+) — quark   (31.10.2006 20:47 62.140.241.223, 285 байт)
        
        Нет ничего я там не ошибся... Там умножаются два 32-битных (+) — ASergej_R19   (31.10.2006 20:51 80.250.160.170, 142 байт)
        
        Ааа... это меня пост про последний гвоздь попутал.. Там числа вроде как 16 бит. — quark   (31.10.2006 21:00 62.140.241.223, пустое, ссылка)
        
        С последним утверждением я не спорю и не возражал против него. Просто пример Вы привели, на мой взгляд, не очень удачный для демонстрации этого утверждения. Вот там-то я и завозражал. — homekvn   (31.10.2006 20:05 212.185.161.237, пустое)
        
        А я начал возражать Вам, потому что Вы возражали неправильным применением fixed point... :-) (+) — ASergej_R19   (31.10.2006 20:21 80.250.160.170, 398 байт)
        
        Ну, про точность я готов продолжить. Приведите, если Вам не трудно, пример наихудшего для floating-point вычислений вектора, где бы начались проблемы с точностью, но при этом 32-битный fixed-point подобных проблем бы не имел. — homekvn   (31.10.2006 20:29 212.185.161.237, пустое)
        
        Не в состоянии прочитать всю дискуссию, но сейчас особенно моден формат ieee754. Каковой для флоата обычного оговаривает на все прол все 32-х разряда. С учетом этого сложите во float 2 числа и доложите результат. Первое число=1073741823, второе =1073741822. — -=ВН=-   (31.10.2006 20:38 193.125.71.140, пустое)
        
        Ну-у! Так и я могу. А теперь Вы сложите серию чисел вроде 8.21e+48 или (e-48), которые также соответствуют приведенному Вами стандарту. И потом Вы мне исходные числа приведите, которые надо в квадрат возвести, а потом просуммировать. А потом сами на блекфине сделайте то же самое. — homekvn   (31.10.2006 21:08 212.185.161.237, пустое)
        
        Вы подменили вопрос. 8.21e+48 не входят в ДИАПАЗОН 32-х разрядных чисел целых. Не входят. А приведенные мной числа в ДИАПАЗОН флоата одинарной точности входят. Я ведь не просил Вас складывать в одинарном флоате числа порядка 8.21e+16799. Нехорошо, нехорошо, Вы пытаетесь меня обмануть :-((( — -=ВН=-   (31.10.2006 21:18 193.125.71.140, пустое)
        
        Да признаюсь, перебрал. Докладываю результат 3,9999997 И что? Кстати (+) — homekvn   (31.10.2006 21:41 212.185.161.237, 635 байт)
        
        Да где Вы видели, что кто-то Ваш Шарк принижал? :-) Это ж разные процессоры, заточены под разные вещи... (+) — ASergej_R19   (31.10.2006 22:05 80.250.160.170, 339 байт)
        
        Вы знаете, я как-то догадывался, что Шарик и с целыми числами умеет, я даже с шариком работал, правда это было давно, шарик старый был, 21065, подох наверное уже. И мне в общем по барабану, кто кого сделает, шарик блэкфина или наоборот. Вы задаете вопрос или приводите пример, я Вам в ответ на это и только на это и демонстрирую всякие ноу и даже хау. — -=ВН=-   (31.10.2006 21:48 193.125.71.140, пустое)
        
        Да про целые числа - это я так... на всякий случай (+) — homekvn   (31.10.2006 21:52 212.185.161.237, 310 байт)
        
        А Вы что, считаете, что я все читал в этой ветке, что ли? Чтобы знать, что речь шла о точности RMS? Вы спросили про наихудший вектор - я привел пример. Хотя назвать его — -=ВН=-   (31.10.2006 22:01 193.125.71.140, 133 байт)
        
        Да, по результату, впрочем Вы и сами догадываетесь, что он немного неточен. Увы. — -=ВН=-   (31.10.2006 21:49 193.125.71.140, пустое)
        
        Еще раз замечу, что если мне понадобится сложить два 32битных числа, я это сделаю просто в int. А что касается точности RMS, то пока подходящий пример не был приведен. — homekvn   (31.10.2006 21:54 212.185.161.237, пустое)
        
        Кстати на BF, если надо будет сложить два 32-битных числа я это тоже сделаю просто строчкой R0 = R1 + R2... :-) (-) — ASergej_R19   (31.10.2006 22:09 80.250.160.170, пустое)
        
        Да ради бога, складывайте, но у Вас был вопрос о наихудшем вектрое для флоат. — -=ВН=-   (31.10.2006 22:04 193.125.71.140, пустое)
        
        Отлично! :-) (+) — ASergej_R19   (31.10.2006 20:42 80.250.160.170, 289 байт)
        
        Очень хорошо! Вот и давайте Ваш пример рассмотрим (Пример ВН оставлю на закуску) (+) — homekvn   (31.10.2006 20:56 212.185.161.237, 530 байт)
        
        Ответ... (+) — ASergej_R19   (31.10.2006 21:08 80.250.160.170, 322 байт)
        
        Хорошо. Показываю (+) — homekvn   (31.10.2006 21:32 212.185.161.237, 928 байт)
        
        Нет... Вы упрощаете мантиссу беря частный вариант и тем совершаете ошибку... (+) — ASergej_R19   (31.10.2006 21:39 80.250.160.170, 251 байт)
        
        Скажу даже больше... (+) — ASergej_R19   (31.10.2006 21:47 80.250.160.170, 89 байт)
        
        Так Вы RMS отыщите, RMS... — homekvn   (31.10.2006 21:48 212.185.161.237, пустое)
        
        Хорошо... Вот Вам вводные... (+) — ASergej_R19   (31.10.2006 22:00 80.250.160.170, 234 байт)
        
        Тогда давайте совсем по-честному. Я попрошу Вас найти среднеквадратичное от чисел квадраты коих Вы привели выше. Сообщите результат. То же сделаю и я. (+) — homekvn   (31.10.2006 21:46 212.185.161.237, 464 байт)
        
        Как только разница между числами станет меньше разрядности мантиссы - флоат начнет давать ошибку... (+) — ASergej_R19   (31.10.2006 21:22 80.250.160.170, 136 байт)
        
        Либо разница между числами больше разрядности мантиссы - тоже флоат будет с ошибкой... Вобщем - разрешающая способность у флоата хуже - о чем я и писал... (-) — ASergej_R19   (31.10.2006 21:27 80.250.160.170, пустое)
        
        Вот кстати и так тоже можно... (-) — ASergej_R19   (31.10.2006 19:41 80.250.160.170, пустое)
        
        В силу последнего замечания для нахождения RMS Блекфин даже и точнее-то ну никак не будет (ввиду обязательной нормировки входного вектора). — homekvn   (31.10.2006 19:33 212.185.161.237, пустое)
        
        Конечно все познается в сравнении... (+) — ASergej_R19   (31.10.2006 17:14 80.250.160.170, 635 байт)
        
        Да я не собираюсь их обижать :-) так что можете не защищать (+) — homekvn   (31.10.2006 17:33 212.185.161.237, 219 байт)
        
        Ну да... Я об этом и говорил, поэтому и сравнивать их какое-то неправильное занятие... (-) — ASergej_R19   (31.10.2006 17:36 80.250.160.170, пустое)
        
        Сравнивать-то в принципе можно, но только тогда, когда речь идет о конкретной задаче и о том, какой проц из двух для нее взять: Блекфин или Шарк. — homekvn   (31.10.2006 18:29 212.185.161.237, пустое)
        
        Ответ: — st256   (31.10.2006 17:06 217.151.231.218, 53 байт)
        
        Очепятка: Шарк, конечно же, не только для аудиосигналов годится. — homekvn   (31.10.2006 16:50 212.185.161.237, пустое)
- Эээ... А у меня тоже входной сигнал варьируется в районе 120 дБ... (+) — ASergej_R19 (31.10.2006 13:49 80.250.160.170, 494 байт)
  - Ответ (+) — homekvn (31.10.2006 14:42 212.185.161.237, 1741 байт)
    - Ответ: — st256 (31.10.2006 14:52 217.151.231.218, 156 байт)
      - Ответ (+) — homekvn (31.10.2006 15:33 212.185.161.237, 776 байт)
        
        Добавлю (+) — homekvn (31.10.2006 15:37 212.185.161.237, 286 байт)
  - Ответ: — st256 (31.10.2006 14:11 217.151.231.218, 304 байт)

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