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

[an error occurred while processing this directive] 2 yes - про перемножение матриц (+)

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

Отправлено SM 26 июля 2005 г. 10:29

на вскидку 10 тактов на два столбца. Для вектора юзаем циркулярную адресацию, чтоб пойнтер сам перекручивался на начало после 8 dual mac

занулить аккумулятор1 || занулить аккумулятор2
8 х dual mac
dual store || занулить акк1
занулить акк2
8 x dual mac
dual store || занулить акк1
занулить акк2
8 x dual mac
dual store || занулить акк1
занулить акк2
8 x dual mac
dual store

итого 40 тактов без учета инициализации пойнтеров

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

Ответы

ну то есть быстрее быстрого алгоритма :). в этом случае у BF тоже самое — yes (26.07.2005 11:24 194.133.69.2, 604 байт)
- Если: все данные - 16 бит со знаком, матрица транспонирована (столбцы лежат по горизонтали), не учитываем накладные расходы на начальные загрузки адресных регистров, правильно разнесены саб-банки памяти, чтоб не было коллизий.... то 34 такта :) — Зок Мёдов (26.07.2005 14:33 212.34.54.6, 2679 байт)
- Вопрос (+) — SM (26.07.2005 13:52 213.141.159.26, 121 байт)
  - A0, A1 - 40-битные аккумуляторы (2шт), I0,I1,I2,I3 - индексные регисты (4-шт). — quark (26.07.2005 14:05 213.171.38.20, пустое)
    - ну BF как бы 2 в 1. там есть любимые ДСП-шниками Ax, Ix и т.п. но есть и Px SP FP пользуемые компилятором — yes (26.07.2005 14:33 194.133.69.2, 29 байт)
      - А тогда скажите, чем же БФ "ортогональнее" 55-го (+) — SM   (26.07.2005 14:38 213.141.159.26, 418 байт)
        
        для меня важный критерий - выход компилятора — yes   (26.07.2005 14:52 194.133.69.2, 165 байт)
        
        Да, на счет С компилера я согласен (+) — SM   (26.07.2005 14:57 213.141.159.26, 141 байт)
        
        Вот про это речь — SM   (26.07.2005 15:00 213.141.159.26, пустое, ссылка)
        
        а сколько времени симулятор (ССS) то 77М считал? — yes   (26.07.2005 16:37 194.133.69.2, пустое)
        
        Я на эмуляторе на реальном проце считал. Там аппаратный клок-каунтер есть. — SM   (26.07.2005 16:39 213.141.159.26, пустое)
        
        Симулятору как то не доверяется... Вдруг какой stall упустит где-то :) — SM   (26.07.2005 16:43 213.141.159.26, пустое)
        
        тоже на эмуляторе 87794601 - выпало в out=1 но нужно заметить — yes   (26.07.2005 16:54 194.133.69.2, 339 байт)
        
        Ну вот вам и сравнение... Я ведь специально на ETSI делал, чтобы от хитростей компилера абстрагироваться. Только за счет 700M :) но и то, жрать-то он тоже на все 700 будет. — SM   (26.07.2005 16:58 213.141.159.26, пустое)
        
        но минимальные изменения, которые pin сделал - позволяют 10% выиграть, а исходник, он от С все-таки далек — yes   (26.07.2005 17:06 194.133.69.2, пустое)
        
        Кстати я боюсь, что pin просто гонял в симуляторе, что не учло каких-нибудь stall'ов с памятью. — SM   (26.07.2005 17:36 213.141.159.26, пустое)
        
        Нет, все честно проверено в железе. — -рin-   (26.07.2005 20:15 195.239.5.142, пустое)
        
        Тогда странно что результаты разные... — SM   (27.07.2005 00:01 213.141.159.26, пустое)
        
        я взял как есть, а pin провел минимальную оптимизацию (может в комментарий на сахаре не все влезло) — yes   (27.07.2005 10:26 194.133.69.2, пустое)
        
        Оп. А там комментарии смотреть можно? Щас... — SM   (27.07.2005 10:31 213.141.159.26, пустое)
        
        Ага нашел... А циркулярная это не честно :) Пересылки в памяти тоже в тест входят :) — SM   (27.07.2005 10:33 213.141.159.26, пустое)
        
        Я ему (VDSP) помог мало-мало :). Исходники по ссылке — -рin-   (27.07.2005 10:46 212.46.4.38, пустое, ссылка)
        
        Да, и все же пересылка памяти в FIR это часть теста на производительность. Циркулярность (+) — SM   (27.07.2005 11:01 213.141.159.26, 107 байт)
        
        А в чем суть (+) — SM   (27.07.2005 11:00 213.141.159.26, 132 байт)
        
        Помнится, без этого получался плохой медленный код. Ручная оптимизация на Си. — -рin-   (27.07.2005 11:41 212.46.4.38, пустое)
        
        Да не, я не против таких изменений, которые не меняют сути происходящего, в отличие от применение циркулярки. Просто интересно. — SM   (27.07.2005 14:37 195.225.131.183, пустое)
        
        помоему (сори за повтор) - слабое место BF это мало шин (ну или их негибкость) — yes   (27.07.2005 10:43 194.133.69.2, 574 байт)
        
        Ответ: (+) — SM   (27.07.2005 10:51 213.141.159.26, 929 байт)
        
        ну и пересылки идут словами (16 бит) соотв в 2раза. а причина тормозов — yes   (27.07.2005 11:07 194.133.69.2, 204 байт)
        
        Так кто мешает компилятору (+) — SM   (27.07.2005 11:13 213.141.159.26, 238 байт)
        
        компиляторы, наверно, хитрое дело - лично я ни одного не написал :) и какие там есть трудности слабо представляю — yes   (27.07.2005 11:19 194.133.69.2, 104 байт)
        
        Ну нету в C функций арифметики с насыщением... Не могу я тут ничего поделать. А я вообще без изменений собирал, как будто бы собирал бы какой-нить уворованный ITU-исходник. — SM   (26.07.2005 17:08 213.141.159.26, пустое)
        
        Имел в виду конечно дробную арифметику, чтобы со сдвигом. — SM   (26.07.2005 17:11 213.141.159.26, пустое)
        
        а там интристиков куча - нечестно :) давайте брать чистый код с какого-нибудь стандарта — yes   (26.07.2005 15:15 194.133.69.2, пустое)
        
        Так пропишите туда свои. А вообще по идее "gsm.h" должен бы быть в vdsp, это стандартный итушный хидер. — SM   (26.07.2005 15:29 213.141.159.26, пустое)
        
        поддержка ETSI (типа AD на Европу равняется :-) вроде есть, но нужно разбираться — yes   (26.07.2005 15:45 194.133.69.2, 150 байт)
        
        Должно сработать. ETSI оно и в африке ETSI и "basop.h" ихний родной, а не мной придуманный. — SM   (26.07.2005 15:47 213.141.159.26, пустое)
    - То есть обманули меня с ортогональностью.... — SM (26.07.2005 14:08 213.141.159.26, пустое)
      - В смысле (+) — SM   (26.07.2005 14:09 213.141.159.26, 53 байт)
        
        Нет! Это пожалуй самое слабое место у BF. Очень плохие связи между computational and addressing. Можно только скопировать значение туда-сюда и всё. (+) — Зок Мёдов   (26.07.2005 14:44 212.34.54.6, 404 байт)
        
        Ну насчет "идти курить" это и у 55-го один к одному. Против конвейера не попрешь. — SM   (26.07.2005 14:58 213.141.159.26, пустое)
        
        Но можно не только просто копировать, а и практически всю арифметику. Кроме умножений и каких-нибудь спец-инструкций для витерби. — SM   (26.07.2005 15:01 213.141.159.26, пустое)
        
        еще скажите неправильно предсказанный переход. такие вещи легко избегаются АВТОМАТИЧЕСКИМИ средствами — yes   (26.07.2005 14:57 194.133.69.2, 144 байт)
        
        Всё это понятно, и латенси и задержки конвейера. (+) — Зок Мёдов   (26.07.2005 15:22 212.34.54.6, 780 байт)
        
        Как это так (+) — SM   (26.07.2005 15:32 213.141.159.26, 173 байт)
        
        ВААААЩЕ НЕТ! (+) Тоскаааааа..... — Зок Мёдов   (26.07.2005 15:46 212.34.54.6, 1968 байт)
        
        А вот наш ответ чемберлену: (+) — SM   (26.07.2005 15:56 213.141.159.26, 1407 байт)
        
        Понятно. Вот и выкручиваемся как можем. Хотя, надо сказать не без успеха...(+) — Зок Мёдов   (26.07.2005 16:09 212.34.54.6, 409 байт)
        
        Погодите, почему 9 тактов (+) — SM   (26.07.2005 16:12 213.141.159.26, 180 байт)
        
        Там в ADу у них все такие каббалисты отпетые сидят. Нравицца им число наверное :) Но по правде говоря, очень хорошо, что если этот джамп не исполнится, то это займёт всего 1 такт. — Зок Мёдов   (26.07.2005 16:16 212.34.54.6, пустое)
        
        а... тогда понятно. у нас хоть треснись 6/5 тактов. Одно утешает, можно припараллелить что-нибудь. — SM   (26.07.2005 16:20 213.141.159.26, пустое)
        
        но для полноты картины надо упомянуть и — yes   (26.07.2005 15:53 194.133.69.2, 349 байт)
        
        Я про пойнтеры (IF CC DPreg = DPreg ) говорил, но всё равно это очень скупо.... — Зок Мёдов   (26.07.2005 16:02 212.34.54.6, пустое)
        
        btw: статическое предсказание используется во многих архитектурах - например PPC — yes   (26.07.2005 15:31 194.133.69.2, 256 байт)
        
        По сравнению с SHARC у которого есть даже кондишнл load/store (с которого меня судьба перевела на BF) move coвсем не рулит... — Зок Мёдов   (26.07.2005 15:51 212.34.54.6, пустое)
        
        Да это понятно, что автоматическими. Если например заюзаешь регистр адресный, когда он еще не готов, то просто конвейер в stall встанет. И всех делов. — SM   (26.07.2005 15:05 213.141.159.26, пустое)
        
        на этапе компиляции. — yes   (26.07.2005 15:16 194.133.69.2, пустое)
        
        Ну даже если NOPов забыть вставить при компиляции, так их само ядро вставит. Конвейер же вроде полностью защищенный. У 55 по крайней мере. — SM   (26.07.2005 15:30 213.141.159.26, пустое)
        
        ну зачем nop-ов почему бы не мулов/эдов? а у BF много чего отлавливается в run-time (куча аппаратных эксепшенов) - это зря, по-моему — yes   (26.07.2005 15:34 194.133.69.2, пустое)
        
        Потому как (+) — SM   (26.07.2005 15:37 213.141.159.26, 230 байт)
        
        Собственно... спору нет, пусть себе останавливается... но только по 5 баксов и не центом больше! :)) — Зок Мёдов   (26.07.2005 15:53 212.34.54.6, пустое)
        
        Так собственно-то (+) — SM   (26.07.2005 16:02 213.141.159.26, 109 байт)
        
        Ессно стопанёт! Но...мееелким мелким шрифтом...читайте еррату очч внимательно :)) Хотя, если не особо извращаться, то всё нормально работает. — Зок Мёдов   (26.07.2005 16:12 212.34.54.6, пустое)
        
        Я вот, господа, ем сейчас булочку с маком и думаю... стопанёт... или не стопанёт? :)) — Зок Мёдов   (26.07.2005 16:20 212.34.54.6, пустое)
        
        Зависит от качества мака :) А на самом-то деле что? стопанёт? — SM   (26.07.2005 16:26 213.141.159.26, пустое)
        
        Нет... похоже не стопануло. А всё потому что в моменты остановки жевательного конвейера, вставлял инструкции из кофе-выпивательного :) — Зок Мёдов   (26.07.2005 16:37 212.34.54.6, пустое)
        
        Ну я ведь серьезно... Защищенный там конвейер или нет? И если защищенный то насколько полно? — SM   (26.07.2005 16:44 213.141.159.26, пустое)
        
        Абсолютно защищённый и безопасный. Единственно, по поводу ерраты. (+) — Зок Мёдов   (26.07.2005 16:54 212.34.54.6, 562 байт)
        
        Ок, спасибо. — SM   (26.07.2005 16:58 213.141.159.26, пустое)
        
        Вот.. откомпилил, в исходниках ничего не менял (+) — Зок Мёдов   (26.07.2005 17:22 212.34.54.6, 171 байт)
        
        Наверное числа неправильные вбил из отчета про секции кода и данных. — -рin-   (26.07.2005 20:33 195.239.5.142, пустое)
        
        Вот правильные ... (+) — Зок Мёдов   (27.07.2005 13:52 212.34.54.6, 1033 байт)
        
        Сорри, не туда запостил.... — Зок Мёдов   (26.07.2005 17:25 212.34.54.6, пустое)
        
        Ну я-то откуда знаю, не я же компилил! — SM   (26.07.2005 17:25 213.141.159.26, пустое)
        
        Уфф... У нас слава кому-то там еррату на ядро прикончили полностью. — SM   (26.07.2005 16:14 213.141.159.26, пустое)
        
        ну дык я о том же и говорю - железо проще софт сложнее - пусть программисты напрягаются пока эмбедеры в конфе трепятся :) — yes   (26.07.2005 15:47 194.133.69.2, пустое)
        
        Так автоостанов конвейера как раз и отмазывает (+) — SM   (26.07.2005 15:58 213.141.159.26, 148 байт)
        
        ну полной ортогональносте и в ARM-е нет - R15 - PC, R14 - SP (при переключении имеет тень) — yes   (26.07.2005 14:42 194.133.69.2, 366 байт)
        
        Совсем ортогональная была вроде PDP-11. — SM   (26.07.2005 14:43 213.141.159.26, пустое)
        
        И очень красивая :) Хоть и простоватая. — SM   (26.07.2005 14:43 213.141.159.26, пустое)
        
        Нет, насколько я помню.. — quark   (26.07.2005 14:10 213.171.38.20, пустое)
- Я кстати обманулся (+) — SM (26.07.2005 11:39 213.141.159.26, 2715 байт)
  - А теперь давайте ту самую мою задачу (+) — SM (26.07.2005 12:17 213.141.159.26, 1296 байт)
    - софтверно это решается вроде бы только циклом - есть побитные — yes (26.07.2005 15:10 194.133.69.2, 372 байт)
      - К сожалению данный поток именно приходит по спорту №1 и уходит по спорту №2 (+) — SM   (26.07.2005 15:27 213.141.159.26, 461 байт)
        
        А вот вам очередная команда хитрая от нас (+) — SM   (26.07.2005 15:42 213.141.159.26, 1277 байт)
        
        ну что теперь мануалы будем цитировать :) — yes   (26.07.2005 15:57 194.133.69.2, 284 байт)
        
        Да я смотрю уже и без спец-команд спец-юнитов (+) — SM   (26.07.2005 16:09 213.141.159.26, 102 байт)
        
        Да ладно... всё мы о грустном только.(+) — Зок Мёдов   (26.07.2005 16:34 212.34.54.6, 546 байт)
        
        Да вот как-то все время получается, что загружаю я проц под самое нехочу... А насчет проигрыша (+) — SM   (26.07.2005 16:47 213.141.159.26, 168 байт)
        
        По плотности кода? Это не очень смешно.... (+) — Зок Мёдов   (26.07.2005 17:03 212.34.54.6, 489 байт)
        
        да там добавить надо #define ETSI_SOURCE #include <fract.h> и убрать аналогичный ти-шный инклуд — yes   (26.07.2005 17:10 194.133.69.2, пустое)
        
        Не-не, сорри, я не про плотность кода, я про такты... про скорость. — SM   (26.07.2005 17:05 213.141.159.26, пустое)
        
        Да, а из библиотек по идее только стартап там должен пристегнуться да деление. — SM   (26.07.2005 17:16 213.141.159.26, пустое)
        
        Так что там про LFSR-то? Сколько оно у вас тактов с учетом взятия из памяти и сования обратно? — SM   (26.07.2005 16:01 213.141.159.26, пустое)
    - Вопрос(+) — quark (26.07.2005 14:43 213.171.38.20, 166 байт)
      - Нет (+) — SM   (26.07.2005 14:55 213.141.159.26, 567 байт)
        
        Ответ: (+) — quark   (27.07.2005 09:23 213.171.38.20, 1116 байт, ссылка)
        
        Кстати, а есть команда у него A = (B << N) >> M, как была в старых добрых шарках? Для добычи битового поля? — SM   (27.07.2005 10:06 213.141.159.26, пустое)
        
        Нету. Для добычи битового поля рекомендуют Rz = extract(Rx,Ry.L)(Z|X). — quark   (27.07.2005 10:50 213.171.38.20, пустое)
        
        Ну она же наверное эту операцию и выполняет... У меня нет просто описания системы команд БФ под рукой — SM   (27.07.2005 10:56 213.141.159.26, пустое)
        
        Думаю, что ту же, судя по мнемонике.. Но Shark-и я не застал... — quark   (27.07.2005 11:11 213.171.38.20, 403 байт)
        
        Да это оно — SM   (27.07.2005 11:14 213.141.159.26, пустое)

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

E-mail: info@telesys.ru

Ответы

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