профилирование и оптимизация на arm Опции

[bzzz77]

день добрый,

осваиваю lpc2478, хотел бы понять как на arm принято профилировать и оптимизировать код. скажем запустил я helix mp3 decoder с буферами в sdram. интересно на что такты уходят. на x86 все просто - есть perf counters, покажут и cache miss и branch misprediction, прочее и понятно где можно начинать копать. а что делать на arm? только симулятор?

спасибо

[scifi]

Можно измерять время выполнения участков кода. Что-то вроде start_timer() и stop_timer(). Если есть сомнения в калибровке таймера, то set_pin_high() и set_pin_low(), а измерение времени - осциллографом на ножке МК. Как-то так.

[bzzz77]

Можно измерять время выполнения участков кода. Что-то вроде start_timer() и stop_timer(). Если есть сомнения в калибровке таймера, то set_pin_high() и set_pin_low(), а измерение времени - осциллографом на ножке МК. Как-то так.

про таймеры тоже понятно, конечно. но вообще я еще рассчитывал на "что-нибудь" чтобы позволило оценить не только время исполнения, но накладные расходы на sdram, например. в любом случае спасибо.

[sergeeff]

про таймеры тоже понятно, конечно. но вообще я еще рассчитывал на "что-нибудь" чтобы позволило оценить не только время исполнения, но накладные расходы на sdram, например. в любом случае спасибо.

Ну и кто вам мешает, если очень любопытно, запустить тестовую процедуру в ram и sdram. Померить разницу и быть счастливым?

[bzzz77]

Ну и кто вам мешает, если очень любопытно, запустить тестовую процедуру в ram и sdram. Померить разницу и быть счастливым?

это можно. а остальное как глядеть? вот тут посоветовали etm - хотя бы почитаю про него.

[sergeeff]

это можно. а остальное как глядеть? вот тут посоветовали etm - хотя бы почитаю про него.

Почитайте, почитайте. Потом посмотрите сколько это стоит, а потом изучите, работает ли он с вашим компилятором, а потом есть ли etm в вашем процессоре и выведен ли он как надо и прочее. Тогда выяснится, что пиписькомера с осциллографом вам вполне хватит. По крайней мере, на первое время.

[bzzz77]

Почитайте, почитайте. Потом посмотрите сколько это стоит, а потом изучите, работает ли он с вашим компилятором, а потом есть ли etm в вашем процессоре и выведен ли он как надо и прочее. Тогда выяснится, что пиписькомера с осциллографом вам вполне хватит. По крайней мере, на первое время.

про осциллограф я пока не понял. вот захотел я узнать места где много времени тратится на доступ к памяти, то есть произошел cache miss. куда я осциллографом буду тыкать?

[sergeeff]

про осциллограф я пока не понял. вот захотел я узнать места где много времени тратится на доступ к памяти, то есть произошел cache miss. куда я осциллографом буду тыкать?

А что, вы думаете ETM вам про cache miss расскажет?

Это во-первых.

Во-вторых, не понимаю разговоров про ловлю микросекундных блох в миллисекундных процедурах. Или задача не по зубам выбранному процессору, или алгоритм хромает. А cache miss - дело десятое.

Примеров тому не счесть. Вот вчера видел очередной вопрос про AVR, где в main() три переменные float....

[bzzz77]

А что, вы думаете ETM вам про cache miss расскажет?

Это во-первых.

Во-вторых, не понимаю разговоров про ловлю микросекундных блох в миллисекундных процедурах. Или задача не по зубам выбранному процессору, или алгоритм хромает. А cache miss - дело десятое.

Примеров тому не счесть. Вот вчера видел очередной вопрос про AVR, где в main() три переменные float....

не понимаете и ладно. видимо никогда не сталкивались с ситуациями когда производительность ощутимо падает если, например, две связанные переменные попадают в разные cacheline. вас послушать, так вместо оптимизации (и алгоритма тоже) нужно сразу из пушек по воробьям палить. с задержками в sdram, cache miss очень хорошо производительность может испортить.

Я думал, речь идёт об LPC2478. Если я правильно помню, никакого кэша там нет. Или это уже просто "разговор за жизнь"?

кэша нет, ступил я слегка. но есть разница в доступе к sdram и sram, значит perf counters (или etm) мог бы помочь в правильной организации: что положить в sram, что в sdram. например.

ps. слегка удивляют люди, которые утверждают, что инструмент - лишний и гвозди можно забивать топором.

[AlexandrY]

значит perf counters (или etm) мог бы помочь в правильной организации: что положить в sram, что в sdram. например.

Что за perf counters?
Если те что по ссылке http://msdn.microsoft.com/en-us/library/aa...3(v=vs.85).aspx, то портируйте Win CE и получите их.

Прецизионных счетчиков в микроконтроллерах полно, выбираете любой и измеряете длительность любых процедур с точностью до такта.
В микроконтроллерах измерения можно сделать гораздо проще и гибче чем в в Windows и с меньшими накладными.

Если вы не используете операционку с готовым фреймворком для счетчиков прозводительности, то понятно что в свой код счетчики надо вставлять самому.
Все серьезные RTOS под микроконтроллеры имеют механизм "Performance Counters"

[bzzz77]

Что за perf counters?
Если те что по ссылке http://msdn.microsoft.com/en-us/library/aa...3(v=vs.85).aspx, то портируйте Win CE и получите их.

Прецизионных счетчиков в микроконтроллерах полно, выбираете любой и измеряете длительность любых процедур с точностью до такта.
В микроконтроллерах измерения можно сделать гораздо проще и гибче чем в в Windows и с меньшими накладными.

Если вы не используете операционку с готовым фреймворком для счетчиков прозводительности, то понятно что в свой код счетчики надо вставлять самому.
Все серьезные RTOS под микроконтроллеры имеют механизм "Performance Counters"

ос слегка не в курсе того, что происходит в ядре процессора. оно же не в курсе ситуаций типа cache hit/miss, branch midprediction и прочих вещей, которые придумали, чтобы мы с ними боролись.

в новых армах есть вот такое, например: http://oprofile.sourceforge.net/docs/arm-v7-events.php

а на v4 похоже только etm

[sergeeff]

ос слегка не в курсе...
в новых армах есть вот такое,.. н
а на v4 похоже только etm

Вы все рассказываете, как оно где-то должно быть очень здорово. Про всякие "новые" ARM'ы, a на конкретные вопросы отвечать не любите.

Если команда вместо 1 такта выполняется за 30 тактов - подсказать вам cache miss или hit там имел место ?

Даже если бы у меня был ETM на борту и весь инструментарий, вы как себе представляете вылавливание таких команд (1 против 30) в программе более 1Мб? Учитывая статистический механизм срабатывания кеша?

Современные технологии программирования с использованием JIT компиляции

Читаем Wiki : (http://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F)
технология увеличения производительности программных систем, использующих байт-код, путём компиляции байт-кода в машинный код непосредственно во время работы программы. Таким образом достигается высокая скорость выполнения (сравнимая с компилируемыми языками) за счёт увеличения потребления памяти (для хранения результатов компиляции) и затрат времени на компиляцию.

Вы действительно считаете, что такая технология - благо для embedded processor? И как вы себе представляете постоянное размещение программы в кеше, если объем программы/данных превышают объемы соответствующих кешей?

[bzzz77]

Вы действительно считаете, что такая технология - благо для embedded processor? И как вы себе представляете постоянное размещение программы в кеше, если объем программы/данных превышают объемы соответствующих кешей?

считаю, что это благо для любого CPU. никакое полное размещение кода в кэше никому не нужно. размещать там нужно критические куски. то же самое касается данных. сейчас мне это потребовалось для декодирования mp3. когда я работаю с intel/amd, то у меня под рукой есть oprofile, которые однозначно покажет "горячие" места, над которыми стоит думать-работать-оптимизировать. например, поднапрячься и переписать их на асме. например, подумать как лучше разместить данные (с учетом наличия sram, который ссуть тот же кэш), использовать возможности разных там burst mode и прочее. однако как я узнаю "горячие" места на lpc2438? ну да, придется расставлять кучу счетчиков клоков тут и там, интеративно приближаясь к "горячим" точкам. только с oprofile (который просто показывает perf counters) это делается за одну итерацию. поглядите какие есть счетчики на разных камнях: http://oprofile.sourceforge.net/docs/

Performance Counters - это программный фреймворк на базе оси.
А для архитектуры с недетминированным временем выполнения но требованием жесткого реалтайма Performance Counters недостаточно.
Нужна статистика и оценки параметров статистики.
Это делается на ARM-ах элементарно, но тоже программно.

курите мат. часть: http://oprofile.sourceforge.net/docs/ - внизу страницы. perf. counters - это счетчики внутри CPU. для того, чтобы с ними работать ось не нужна. максимум, что требуется от оси - не мешать, давать доступ к ним.

Хороший, годный срач получился.
Чем засорять тему дальше, почему бы не сойтись на том, что ARM7TDMI не имеет аппаратных Performance Counters, и средства измерения производительности должны добавляться к программе вручную?

похоже так зассучив рукава ... вот с ETM можно было бы много интересной информации получить, я полагаю. но под нынешний проект - это слишком большой объем работ получится. в любом случае, за подсказку про ETM спасибо подсказавшим.

[AlexandrY]

курите мат. часть: http://oprofile.sourceforge.net/docs/ - внизу страницы. perf. counters - это счетчики внутри CPU. для того, чтобы с ними работать ось не нужна. максимум, что требуется от оси - не мешать, давать доступ к ним.

Я вам уже дал ссылку: http://msdn.microsoft.com/en-us/library/aa...3(v=vs.85).aspx
Не ней невооруженным взглядом видно что на PC вы имеете дело не со счетчиками напрямик, а с программным инструментом,
без которого от тех счетчиков ни холодно ни жарко.
B RTOS есть такие же программные инструменты.

Или скажем так. Покажите хоть один счетчик в PC-шном проце который бы вам помог узнать наиболее узкое место в алгоритме

[bzzz77]

Я вам уже дал ссылку: http://msdn.microsoft.com/en-us/library/aa...3(v=vs.85).aspx
Не ней невооруженным взглядом видно что на PC вы имеете дело не со счетчиками напрямик, а с программным инструментом,
без которого от тех счетчиков ни холодно ни жарко.
B RTOS есть такие же программные инструменты.

Или скажем так. Покажите хоть один счетчик в PC-шном проце который бы вам помог узнать наиболее узкое место в алгоритме

пожалуйста, прекратите ссылаться на тупейшие документы майкрософт и посмотрите то, что я показал выше. там настоящие счетчики, а не какие-то "программные инструменты".

касательно счетчиков в PC - они там же описаны, их полно. я их много раз использовал. современный CPU легко может снизить теоретическую производительность алгоритма во много раз, если не принимать во внимание особенности CPU.

[AlexandrY]

пожалуйста, прекратите ссылаться на тупейшие документы майкрософт и посмотрите то, что я показал выше. там настоящие счетчики, а не какие-то "программные инструменты".

касательно счетчиков в PC - они там же описаны, их полно. я их много раз использовал. современный CPU легко может снизить теоретическую производительность алгоритма во много раз, если не принимать во внимание особенности CPU.

Ну пока инфа от микрософта у меня вызывает больше доверия чем ваша
Да и пакет по вашей ссылке тоже есть по сути чисто программное решение.
Хотя честно скажу, оно мне понравилось, так что от ваших постов польза есть.
Кстати там ответ на вашу проблему.
Организуйте регулярные прерывания и фиксируйте по какому адресу вы прервали алгоритм, пишите адреса в базу данных (огромная правда будет ) или на лету пытайтесь определить имя функции которую прервали и ее пишите в базу (тогда огромный символьный файл нужен будет). После миллиона запусков приложения получите вполне правдоподобную статистику.

Это типа то удобство которое дают профайлеры на PC-ишных процессорах. Смешно, но это костыли.

Простенький симмулятор в Keil-е даст гораздо более подробную и исчерпывающую информацию вплоть до обращений к отдельным периферийным регистрам.
Взяв симуляторы покруче можно и шинные задержки учесть.

И расскажите ка, как вы все таки те счетчики использовали Ну просто интересно. (это при том что у вас не было понятия о текущих DMA обменах, задержках в контроллерах памяти, шинных мостах и т.д. и т.п. ) Т.е. что дает статистика ядра без статистики со всей платформы SoC-а?

[bzzz77]

Ну пока инфа от микрософта у меня вызывает больше доверия чем ваша
Да и пакет по вашей ссылке тоже есть по сути чисто программное решение.
Хотя честно скажу, оно мне понравилось, так что от ваших постов польза есть.

И расскажите ка, как вы все таки те счетчики использовали Ну просто интересно. (это при том что у вас не было понятия о текущих DMA обменах, задержках в контроллерах памяти, шинных мостах и т.д. и т.п. ) Т.е. что дает статистика ядра без статистики со всей платформы SoC-а?

ну вы хоть приличия ради загляните по ссылке, да? http://oprofile.sourceforge.net/docs/intel-piii-events.php - это счетчики *внутри* CPU. oprofile/проч их только показывают. где оно "чисто программное" ? ну или почитайте шиты от intel/amd.

раз так интересно - расскажу. oprofile (или другой похожий) покажет точки в коде, на который счетчики чаще всего срабатывают: http://oprofile.sourceforge.net/examples/

дальше - по ситуации, которых масса. например, есть структуры, связанные в список, по которым постоянно делается поиск (hash-листы, деревья). структура может быть достаточно большая и не влазить целиком в cache line. кто-то (может быть и сам) организовал структуру так, что указатель на следующий элемент находится в одной cache line, а "ключ" - в другой. потребуется два обращения к памяти. а можно положить указатель и ключ в пределах одной cacheline и обойтись одним обращением к памяти. есть branch prediction/misprediction. есть обращения к tlb. есть отдельный и большой класс ситуаций, связанных с SMP, с NUMA. для всех них тоже *обычно* есть счетчики, которые позволяют оценить расходы и производительность *существующего* кода. и искать неоптимальные места не наобум, не методом тыка, не путем изучения кучи кода. со счетчиками я вижу, где чаще всего бывают обращения к памяти (а не к кэшу), где чаще всего бранчи предсказывают неверное и так далее.


Сообщение отредактировал bzzz77 - Mar 7 2011, 16:40

[AlexandrY]

ну вы хоть приличия ради загляните по ссылке, да? http://oprofile.sourceforge.net/docs/intel-piii-events.php -

Так, исчо раз.
Решение это программное. В памяти сидит демон, он во первых оказывает неизвестный местный эффект.
Во вторых решение это изолированное, т.е. это не реальная работа программы, а тестовые бесконечные запуски иначе не наберется статистика.

Все это вы можете таким же образом сделать на своем ARM-е.
А какие-то особенные счетчики можете вставить ручками и даже такие каких нет в Core I7 тем боле, что работать с кэшем вам на ARM7TDMI не грозит.
При том в i7 нет тучи счетчиков того, что действительно критически тормозит ARM-ы в SoC-ах.

Про то что там чета не помещается в кэш, а вы героически это решаете, то тоже в данной теме не в кассу.
Есть ARM-ы с TCM памятью специально для жесткого риалтайма, никаких танцев с бубном вокруг кэша.
Т.е. если выбрали неподходящую архитектуру для решения, то пеняйте только на себя, а не на ARM-ы.

[ar__systems]

Так, исчо раз.
Решение это программное. В памяти сидит демон, он во первых оказывает неизвестный местный эффект.

Уважаемый, вы меня пугаете. Вам 10ый раз говорят, эти счетчики не просто регистры процессора, их железо само обновляет. Решение это ХАРДВЕРНОЕ.

[singlskv]

Уважаемый, вы меня пугаете. Вам 10ый раз говорят, эти счетчики не просто регистры процессора, их железо само обновляет. Решение это ХАРДВЕРНОЕ.

Осталось только научиться все эти ХАРДВАРДНЫЕ счетчтики чисто программно считывать в строго детерминированные
моменты времени, особенно при наличии OS...
Здесь без Event System Вы мало что точно намеряете.