Немного поплясал с бубном, вспомнив, что среди результатов квантизации почти 75% нулей (это для всех картинок, так сама идея кодера задумана), следовательно, можно неплохо выиграть, правильно написав условия (т.е. обеспечить кратчайшее время при 0). После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.

Кстати, бекпорт оптимизированного кодера привел к результату 8561325 на AVR (было около 12 миллионов).

И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно).

Вот видите, можете поблагодарить меня за предоставленный стимул..

Спасибо. Кстати, получается, что разрыв с BF сократили до 30%. Я считаю - есть над чем подумать... (не нам с Вами, а тем, кто сейчас чешет репу с вопросом "какую бы каменюку мне в проект заложить";) )

Подумать всегда есть над чем, но нужно не забывать, что конвейер в BF - 10 тактов, а рабочая частота ядра - 600 МГц.

Для быстрого сжатия можно использовать:
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.

1) насколько мне известно, алгоритм JPEG-LS жмет в 3-4 раза, что, IMHO, недостаточно для многих приложений.
2) А что за кадры? Размер кадра? Цвет?
И сколько стоит реализация на FPGA? Есть оценки?

Вы думаете, что DCT - это самое зло? Вы ошибаетесь. Обработка результатов DCT занимает столько же времени, что и само преобразование (хотя бы потому, что необходимо каждую гармонику (а их всего столько же, сколько пикселей) разделить на коэффициент) - причем, это с учетом всех оптимизаций (деление заменено на умножение на 1/q; если делимое меньше делителя, сразу исполняется быстрая обработка нулевого результата). А вот в LS надо над каждым пикселем поплясать немало.

Ну и часто необходим больший коэффициент сжатия.

Очень интересное число. Для общего развития не можете назвать получившееся при этом соотношение размеров кода?

Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.

ARM: 2 232 bytes in segment CODE
AVR: 2 026 bytes in segment CODE
AVR32: 1 910 bytes in segment CODE32

ARM в арме. Тумбу даже пробовать не буду, регистров не хватит, будет дупа по производительности.



Вы читаете то, что я пишу? Если выбросить DCT, то времени займет только в 2 раза меньше

Конечно, если у Вас плохо дело с оптимизацией самого DCT - тогда да.

Для BF по моим оценкам, затраты на DCT -15%, а на сжатие Huffman'ом и все остальное - 85%.
Где тут можно получить выигрыш в 4 раза?

Сообщение отредактировал blackfin - Jun 3 2008, 06:17

Это на BF. Там DCT конечно лучше должно получиться, все-таки несколько MAC за такт.

А на AVR/ARM/AVR32 соотношение 50 на 50.

DCT и преобразование Уолша проверены на реальном продаваемом оборудовании
http://telekadr.by.ru

Совершенно привычные соотношения. Cпасибо.

Это правильно

Гм... Вообщем, нельзя доверять этим симуляторам в иаре... AVR'овский правильно такты считает, а ARM - слишком льстит - B за 1 такт вместо 3, ST за 1 такт вместо 2, LD за 2 такта вместо 3х.. AVR32 тоже далек от правды, причем в другую сторону... Ну для AVR32 я студию выйму, посмотрю, чего она насчитает, а вот для ARM'а... Чем бы таким посимулить поумнее?



Это говорит только о том, что Вы не в теме И оптимизацию, как сейчас модно говорить, ниасилили.



Щас будем пересматривать...