Отправлено yes 26 июля 2005 г. 14:52 В ответ на: А тогда скажите, чем же БФ "ортогональнее" 55-го (+) отправлено SM 26 июля 2005 г. 14:38

писать на ассемблере получается слишком долго...

у BF это хорошо (там логически два ядра - одно с Ax Ix, другое процессорное)

для 55-го С выдает очень плохой код

• Да, на счет С компилера я согласен (+) — 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, пустое)