Переход на THUMB, Имеет ли смысл рассуждение? Опции

[DpInRock]

От at91sam9261 требуется перейти на LPC2478.

Чтобы не заморачиваться особо (с переносом функций в RAM и прочим), дай думаю, запускать все в THUMB, расчитывая на то, что из флэша тубму будет немного способнее извлекаться и соответственно, чуть быстрее исполняться (типа, раз в среднем код короче, то акселератору флэш будет проще).

Но насколько сам THUMB хуже - не могу оценить. Переделка текущего проекта в THUMB (для 9261) никаких видимых (глазу) замедлений не дала.

Но разница между 9261 и 2478 по скорости очень велика, и видимо, это как-то скажется. (Но сейчас 2478 нет в наличии, чтобы проверить).

Вот и нужен совет - делать все как люди делают (часть кода в РАМ, перемежать тумб режим и арм и прочая) или сойдет и так? Т.е. насколько много дают прирост производительности все эти меры?
----
Программа особо ничего не делает, просто выводит текст на экран 480х272 (24 бита). Остальные задачи еще мельче. Ну, еще все это работает под переключателем задач раз в миллисекунду (на базе freeRTOS - в смысле, переключение контекста оттуда).

Сообщение отредактировал DpInRock - Jan 27 2010, 16:33

[DpInRock]

Про сжатие. Я взял JPEG как более понятный. В любом редакторе делается. В отличие от других.
Ну и исходники на дороге прям валяются. Токо успевай копипастить.

Отключение кэша снижает скорость вывода (с декодированием) раза в 2. (На глаз. Хотя скорее всего несколько больше - честно говоря, точно замерять лень, пока разница не бросается в глаза явно).
Действительно, как-то не подумал. Можно ведь снизить частоту ядра очень легко и просто посмотреть.
Хотя, конечно результат будет известен. 198\72 раза медленнее.

У меня нет GUI как такового. На экране токо буковки, цифирки и графики (типа осцилограммы или спектра).
Кнопки все настоящие.

[VslavX]

Отключение кэша снижает скорость вывода (с декодированием) раза в 2. (На глаз.

А Вы "на глаз" не меряйте - сделайте простенький профайлер - uint32 счетчик тикающий по прерыванию с какой-нибудь подходящей частотой - например от 1кГц, при вызове процедуры - счетчик запомнили, вышли из процедуры - вычли из нового значения счетчика (он же в прерывании протикал, верно?) запомненное - вот и получите время исполнения процедуры в "тиках". Тем более, у Вас различия в скорости разных вариантов не на порядки - "на глаз" никак нормально не оцените.

Действительно, как-то не подумал. Можно ведь снизить частоту ядра очень легко и просто посмотреть.

Тут надо аккуратно - ядро 926EJ это не совсем то же самое что ARM7TMDI-S, но разброса в порядки опять-таки не будет.
Насчет собственно перехода на THUMB - можно переходить вполне без особой боязни, по моему опыту - производительность составит 0.8..0.9 от АРМ-овского режима. По моим впечатления (после переписывания нескольких ассемблерных и перекомпиляции C-шных библиотек с ARM на THUMB) от переноса особо "страдают" алгоритмы с частым и неупорядоченным обращением к памяти, типа индексированной выборки из двух-трех массивов - не хватает режимов адресации в THUMB, не знаю как тут JPEG, может он и не в тему будет. Иногда не хватает регистров, но, к моему удивлению - редко, по-крайней мере, на моих задачах (криптография, длинная математика, статобработка). Еще вылез прикол - быстродействие циклов в THUMB на LPC намного заметнее зависит от выравнивания/местоположения кода чем в режиме ARM - думаю, это MAM разыгрался. Но, в целом, впечатления от THUMB остались приятные, проигрывая 10-20% скорости, дает выигрыш по объему кода до полутора раз. BTW, на SAM7 относительные цифры ARM/THUMB были такие же.