Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: профилирование и оптимизация на arm
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
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
Цитата(scifi @ Mar 6 2011, 01:20) *
Можно измерять время выполнения участков кода. Что-то вроде start_timer() и stop_timer(). Если есть сомнения в калибровке таймера, то set_pin_high() и set_pin_low(), а измерение времени - осциллографом на ножке МК. Как-то так.


про таймеры тоже понятно, конечно. но вообще я еще рассчитывал на "что-нибудь" чтобы позволило оценить не только время исполнения, но накладные расходы на sdram, например. в любом случае спасибо.
sergeeff
Цитата(bzzz77 @ Mar 6 2011, 09:32) *
про таймеры тоже понятно, конечно. но вообще я еще рассчитывал на "что-нибудь" чтобы позволило оценить не только время исполнения, но накладные расходы на sdram, например. в любом случае спасибо.


Ну и кто вам мешает, если очень любопытно, запустить тестовую процедуру в ram и sdram. Померить разницу и быть счастливым?
ViKo
В Keil есть Analisis Windows, а именно Logic Anilizer, Performance Analizer, Code Coverage. А также трассировка, а также Execution Profiling. И время выполнения можно засечь в отладчике. Сам почти не пользовался, поэтому насколько это соответствует требуемому, не скажу. На мой взгляд, достаточно.
sasamy
Цитата(bzzz77 @ Mar 6 2011, 00:25) *
день добрый,

осваиваю lpc2478, хотел бы понять как на arm принято профилировать и оптимизировать код.


В lpc2478 есть ETM, нужно всего несколько килодолларов чтобы купить jtag с поддержкой ETM trace sm.gif
sergeeff
До чего все любят усложнять себе (и другим) жизнь!

Вы посмотрите на форуме бесконечно: в отладчике работает, на железе - нет. Килобаксы тратить за каким-то. Вам же посоветовали pin_on/pin_off. Осциллографом замерил - точнее не бывает. На собственном железе, с учетом прерываний, реальной настройки железа. Да и измерять вы будете может раз-два. Вперед!
sasamy
Цитата(sergeeff @ Mar 6 2011, 16:24) *
До чего все любят усложнять себе (и другим) жизнь!

Вы посмотрите на форуме бесконечно: в отладчике работает, на железе - нет. Килобаксы тратить за каким-то. Вам же посоветовали pin_on/pin_off. Осциллографом замерил - точнее не бывает. На собственном железе, с учетом прерываний, реальной настройки железа. Да и измерять вы будете может раз-два. Вперед!



Вообщето ETM как раз трассирует код в реальном времени без воздействия на процесс, а пиписькомер на осциллографе годится только для кода уровня ножкой топ в ладошки хлоп, никакого анализа сложного кода на нем не сделать - вы никогда не поймете почему происходит задержка - вдияние ОС, промахи кеша или просто неоптимальный код.
bzzz77
Цитата(sergeeff @ Mar 6 2011, 14:29) *
Ну и кто вам мешает, если очень любопытно, запустить тестовую процедуру в ram и sdram. Померить разницу и быть счастливым?


это можно. а остальное как глядеть? вот тут посоветовали etm - хотя бы почитаю про него.
sergeeff
Цитата(bzzz77 @ Mar 6 2011, 22:59) *
это можно. а остальное как глядеть? вот тут посоветовали etm - хотя бы почитаю про него.


Почитайте, почитайте. Потом посмотрите сколько это стоит, а потом изучите, работает ли он с вашим компилятором, а потом есть ли etm в вашем процессоре и выведен ли он как надо и прочее. Тогда выяснится, что пиписькомера с осциллографом вам вполне хватит. По крайней мере, на первое время.
bzzz77
Цитата(sergeeff @ Mar 6 2011, 23:51) *
Почитайте, почитайте. Потом посмотрите сколько это стоит, а потом изучите, работает ли он с вашим компилятором, а потом есть ли etm в вашем процессоре и выведен ли он как надо и прочее. Тогда выяснится, что пиписькомера с осциллографом вам вполне хватит. По крайней мере, на первое время.


про осциллограф я пока не понял. вот захотел я узнать места где много времени тратится на доступ к памяти, то есть произошел cache miss. куда я осциллографом буду тыкать?
ar__systems
Меня тоже неприятно удивило отсутсвие в АРМе каких-либо performance counters.
aaarrr
В старших (ARM11, Cortex-Ax) есть.
sergeeff
Цитата(bzzz77 @ Mar 7 2011, 00:01) *
про осциллограф я пока не понял. вот захотел я узнать места где много времени тратится на доступ к памяти, то есть произошел cache miss. куда я осциллографом буду тыкать?


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

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

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

Примеров тому не счесть. Вот вчера видел очередной вопрос про AVR, где в main() три переменные float....
scifi
Цитата(bzzz77 @ Mar 7 2011, 00:01) *
про осциллограф я пока не понял. вот захотел я узнать места где много времени тратится на доступ к памяти, то есть произошел cache miss. куда я осциллографом буду тыкать?

Я думал, речь идёт об LPC2478. Если я правильно помню, никакого кэша там нет. Или это уже просто "разговор за жизнь"?
bzzz77
Цитата(sergeeff @ Mar 7 2011, 10:15) *
А что, вы думаете ETM вам про cache miss расскажет?

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

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

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


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


Цитата(scifi @ Mar 7 2011, 10:37) *
Я думал, речь идёт об LPC2478. Если я правильно помню, никакого кэша там нет. Или это уже просто "разговор за жизнь"?


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

ps. слегка удивляют люди, которые утверждают, что инструмент - лишний и гвозди можно забивать топором.
aaarrr
Цитата(bzzz77 @ Mar 7 2011, 12:58) *
ps. слегка удивляют люди, которые утверждают, что инструмент - лишний и гвозди можно забивать топором.

Лучшим инструментом является все-таки головной мозг. Чтобы решить, что положить в SRAM, а что в SDRAM без кэша, нужен именно он, а никак не ETM c PM.
sergeeff
Цитата(bzzz77 @ Mar 7 2011, 12:58) *
не понимаете и ладно.


Очень рад за вас, понимающий вы наш!

Может статейку в приличном журнале (Dr. Dobb's, например) опубликуете с практическими результатами исследований и рекомендациями, как и что в таких случаях в программе подправить? Как использовать ETM для вылавливания cache miss. Получите наш общий респект и денежку подзаработаете.

Цитата
когда производительность ощутимо падает


Пример в студию! С цифрами, пожалуйста.
sasamy
Цитата(sergeeff @ Mar 7 2011, 13:18) *
Как использовать ETM для вылавливания cache miss. Получите наш общий респект и денежку подзаработаете.


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

Цитата
Пример в студию! С цифрами, пожалуйста.


Современные технологии программирования с использованием JIT компиляции - за счет того что генерируемый код всегда в кеше достигаются такие скорости что вам с вашим ассемблером и осциллографом и не снилось.
AlexandrY
Цитата(bzzz77 @ Mar 7 2011, 11:58) *
значит 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
Цитата(AlexandrY @ Mar 7 2011, 14:47) *
Что за 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 sad.gif
sergeeff
Цитата(bzzz77 @ Mar 7 2011, 15:03) *
ос слегка не в курсе...
в новых армах есть вот такое,.. н
а на v4 похоже только etm sad.gif


Вы все рассказываете, как оно где-то должно быть очень здорово. Про всякие "новые" 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? И как вы себе представляете постоянное размещение программы в кеше, если объем программы/данных превышают объемы соответствующих кешей?
ar__systems
Цитата(AlexandrY @ Mar 7 2011, 06:47) *
Что за perf counters?
Все серьезные RTOS под микроконтроллеры имеют механизм "Performance Counters"

Это все фуйня. У интела начиная с пентиума есть полноценные железячные счетчики, посмотрите. А все эти "фичи" от операционки -- жалкий эрзац.
scifi
Хороший, годный срач получился.
Чем засорять тему дальше, почему бы не сойтись на том, что ARM7TDMI не имеет аппаратных Performance Counters, и средства измерения производительности должны добавляться к программе вручную?
ar__systems
Цитата(sergeeff @ Mar 7 2011, 07:42) *
Даже если бы у меня был ETM на борту и весь инструментарий, вы как себе представляете вылавливание таких команд (1 против 30) в программе более 1Мб? Учитывая статистический механизм срабатывания кеша?

Вы продолжаете тупить. В програмее размером 1 Mb (Гхм... компилированного кода? Вы серьезно?) будет небольшое количество критичного кода, и естественно никто никогда ВСЮ программу не профилирует, даже на PC, где 1МБ как раз не предел. Раз уж взялись википедию читать, почитайте про профилирование.
AlexandrY
Цитата(scifi @ Mar 7 2011, 15:28) *
Хороший, годный срач получился.
Чем засорять тему дальше, почему бы не сойтись на том, что ARM7TDMI не имеет аппаратных Performance Counters, и средства измерения производительности должны добавляться к программе вручную?


Performance Counters - это программный фреймворк на базе оси.
А для архитектуры с недетминированным временем выполнения но требованием жесткого реалтайма Performance Counters недостаточно.
Нужна статистика и оценки параметров статистики.
Это делается на ARM-ах элементарно, но тоже программно.
bzzz77
Цитата(sergeeff @ Mar 7 2011, 15:42) *
Вы действительно считаете, что такая технология - благо для embedded processor? И как вы себе представляете постоянное размещение программы в кеше, если объем программы/данных превышают объемы соответствующих кешей?


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



Цитата(AlexandrY @ Mar 7 2011, 17:11) *
Performance Counters - это программный фреймворк на базе оси.
А для архитектуры с недетминированным временем выполнения но требованием жесткого реалтайма Performance Counters недостаточно.
Нужна статистика и оценки параметров статистики.
Это делается на ARM-ах элементарно, но тоже программно.


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


Цитата(scifi @ Mar 7 2011, 16:28) *
Хороший, годный срач получился.
Чем засорять тему дальше, почему бы не сойтись на том, что ARM7TDMI не имеет аппаратных Performance Counters, и средства измерения производительности должны добавляться к программе вручную?


похоже так sad.gif зассучив рукава ... вот с ETM можно было бы много интересной информации получить, я полагаю. но под нынешний проект - это слишком большой объем работ получится. в любом случае, за подсказку про ETM спасибо подсказавшим.
AlexandrY
Цитата(bzzz77 @ Mar 7 2011, 16:21) *
курите мат. часть: 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-шном проце который бы вам помог узнать наиболее узкое место в алгоритме wink.gif
bzzz77
Цитата(AlexandrY @ Mar 7 2011, 17:40) *
Я вам уже дал ссылку: http://msdn.microsoft.com/en-us/library/aa...3(v=vs.85).aspx
Не ней невооруженным взглядом видно что на PC вы имеете дело не со счетчиками напрямик, а с программным инструментом,
без которого от тех счетчиков ни холодно ни жарко.
B RTOS есть такие же программные инструменты.

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


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

касательно счетчиков в PC - они там же описаны, их полно. я их много раз использовал. современный CPU легко может снизить теоретическую производительность алгоритма во много раз, если не принимать во внимание особенности CPU.
sergeeff
Цитата(bzzz77 @ Mar 7 2011, 18:27) *
... если не принимать во внимание особенности CPU.


... до основанья, а затем, мы наш, мы новый мир построим ...

А что же вы не сказали главного, что ваш любимый oprofile под Linux? Или вы хотите его "легко" на lpc2438 портировать вместе с искомой ОС для "удобного" профилирования "горячих" процедур?
bzzz77
Цитата(sergeeff @ Mar 7 2011, 18:54) *
... до основанья, а затем, мы наш, мы новый мир построим ...

А что же вы не сказали главного, что ваш любимый oprofile под Linux? Или вы хотите его "легко" на lpc2438 портировать вместе с искомой ОС для "удобного" профилирования "горячих" процедур?


не стоит за меня додумывать и пытаться все списать на фанатизм. oprofile и линукс тут не причем. он просто показывает эти счетчики, которые реализованы в cpu. какие счетчики есть - такие и покажет. точно так же работают в базе amd code analyst и intel vtune - вытаскивают эти счетчики. соответственно меня заинтересовали счетчики в arm7tdmi. ну или какие-то другие методы для профилирования на arm. которое, в ряде случаев, сильно помогает.
AlexandrY
Цитата(bzzz77 @ Mar 7 2011, 17:27) *
пожалуйста, прекратите ссылаться на тупейшие документы майкрософт и посмотрите то, что я показал выше. там настоящие счетчики, а не какие-то "программные инструменты".

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


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

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

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

И расскажите ка, как вы все таки те счетчики использовали wink.gif Ну просто интересно. (это при том что у вас не было понятия о текущих DMA обменах, задержках в контроллерах памяти, шинных мостах и т.д. и т.п. ) Т.е. что дает статистика ядра без статистики со всей платформы SoC-а?
sergeeff
Цитата(bzzz77 @ Mar 7 2011, 19:02) *
не стоит за меня додумывать


Отладите свой mp3-проект на lpc, отпишитесь.

Успехов! Счетчик дней начал тикать.
bzzz77
Цитата(AlexandrY @ Mar 7 2011, 19:20) *
Ну пока инфа от микрософта у меня вызывает больше доверия чем ваша biggrin.gif
Да и пакет по вашей ссылке тоже есть по сути чисто программное решение.
Хотя честно скажу, оно мне понравилось, так что от ваших постов польза есть. wink.gif

И расскажите ка, как вы все таки те счетчики использовали wink.gif Ну просто интересно. (это при том что у вас не было понятия о текущих 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. для всех них тоже *обычно* есть счетчики, которые позволяют оценить расходы и производительность *существующего* кода. и искать неоптимальные места не наобум, не методом тыка, не путем изучения кучи кода. со счетчиками я вижу, где чаще всего бывают обращения к памяти (а не к кэшу), где чаще всего бранчи предсказывают неверное и так далее.
AlexandrY
Цитата(bzzz77 @ Mar 7 2011, 18:38) *
ну вы хоть приличия ради загляните по ссылке, да? http://oprofile.sourceforge.net/docs/intel-piii-events.php -


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

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

Про то что там чета не помещается в кэш, а вы героически это решаете, то тоже в данной теме не в кассу.
Есть ARM-ы с TCM памятью специально для жесткого риалтайма, никаких танцев с бубном вокруг кэша.
Т.е. если выбрали неподходящую архитектуру для решения, то пеняйте только на себя, а не на ARM-ы.
bzzz77
Цитата(AlexandrY @ Mar 7 2011, 20:08) *
Так, исчо раз.
Решение это программное. В памяти сидит демон, он во первых оказывает неизвестный местный эффект.
Во вторых решение это изолированное, т.е. это не реальная работа программы, а тестовые бесконечные запуски иначе не наберется статистика.

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

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


прямо параллельная вселенная какая-то, ей-богу. демон, который сидит в памяти - собирает данные, предоставляемые CPU. потому что "программно" узнать как часто бывает cache hit/miss и все остальное - нельзя. следуя вашей логике, можно и видеокарту называть программным решением, ибо ей требуется драйвер. на arm я не могу увидеть в каком-нибудь регистре как много обращений к памяти было, например. не важно есть демон или нет. на intel/amd я могу это сделать, без всякого демона. потому что соответствующий регистр есть и с демоном не уходит.

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

в данной теме много чего не в кассу.

на arm я не пенял. я просто спросил как можно профилировать на arm. в ответ на это вы принялись валить сюда кучу лажи и ничего по существу. извиняйте за прямоту.
AlexandrY
Цитата(bzzz77 @ Mar 7 2011, 19:19) *
бесконечные тестовые запуски весьма даже конечны - например, мне более чем достаточно было декодировать пару мегабайт mp3, чтобы увидеть горячие места и понять где нужно копать.

Я подозреваю что половина из тех кто вам ответил портировала этот несчастный mp3. О его потрировании темы здесь не утихают не на месяц.

И что вам скажет счетчик обращений к абстрактной памяти? Вы что, уберете эти обращения?
Ну так это уже вопрос системного проектирования, а не отладки.
Напороться на него при отладке вот уж действительно лажа.

Ну, какие еще счетчики вспомните?

Гораздо продуктивнее заниматься тюнингом мнгозадачных планировщиков: Lower the overhead in RTOS scheduling
bzzz77
Цитата(AlexandrY @ Mar 7 2011, 20:38) *
Я подозреваю что половина из тех кто вам ответил портировала этот несчастный mp3. О его потрировании темы здесь не утихают не на месяц.

И что вам скажет счетчик обращений к абстрактной памяти? Вы что, уберете эти обращения?
Ну так это уже вопрос системного проектирования, а не отладки.
Напороться на него при отладке вот уж действительно лажа.

Ну, какие еще счетчики вспомните?

Гораздо продуктивнее заниматься тюнингом мнгозадачных планировщиков: Lower the overhead in RTOS scheduling


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

кол-во обращений к sdram я могу сократить, по-другому распределив данные-код между sram/sdram.

"вспоминать" счетчики у меня не выйдет - нет их на arm. на intel/amd можно было бы поглядеть на ошибки переходов, на среднее кол-во тактов на инструкцию и, возможно, переработать код на асме.
sergeeff
Цитата(bzzz77 @ Mar 7 2011, 20:57) *
особого ума портировать не нужно. делается на раз-два-три.

кол-во обращений к sdram я могу сократить, по-другому распределив данные-код между sram/sdram.

"вспоминать" счетчики у меня не выйдет - нет их на arm. на intel/amd можно было бы поглядеть на ошибки переходов, на среднее кол-во тактов на инструкцию и, возможно, переработать код на асме.


Ну-ну. Философия списывающего школьного двоечника.
bzzz77
Цитата(sergeeff @ Mar 7 2011, 21:13) *
Ну-ну. Философия списывающего школьного двоечника.


философия "оскорбить когда сказать нечего" ?
ar__systems
Цитата(AlexandrY @ Mar 7 2011, 12:08) *
Так, исчо раз.
Решение это программное. В памяти сидит демон, он во первых оказывает неизвестный местный эффект.

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


А чего тут говорить. У меня таких студентов было лет ...дцать тому назад немало - "все вокруг идиоты, все сделано неправильно, а я вот счас всех за пояс". Кто-то из них быстро бросил всю эту инженерию, кто-то надорвался, кто-то сумел извлечь уроки и стал поспокойнее, кто-то спился, увы.
bzzz77
Цитата(sergeeff @ Mar 7 2011, 21:42) *
А чего тут говорить. У меня таких студентов было лет ...дцать тому назад немало - "все вокруг идиоты, все сделано неправильно, а я вот счас всех за пояс". Кто-то из них быстро бросил всю эту инженерию, кто-то надорвался, кто-то сумел извлечь уроки и стал поспокойнее, кто-то спился, увы.


спасибо на добром слове. и себя похвалить не забыл - золотой человек. я разве сказал "сделано неправильно"? уже читайте, а не додумывайте.
AlexandrY
Цитата(ar__systems @ Mar 7 2011, 20:37) *
Уважаемый, вы меня пугаете. Вам 10ый раз говорят, эти счетчики не просто регистры процессора, их железо само обновляет. Решение это ХАРДВЕРНОЕ.


Это ничего не меняет! Не счетчики же он профилирует. Счетчики могут выполняться хоть тыщу тактов.
Он эти счетчик враз может сделать по прерываниям в ARM-е.
Демон же у TC не вызывает никакого отторжения.

В ARM-ах есть к счастью всякие исключения которые не препятствуют наделать тучу изощренных счетчиков.
Если же отойти от устаревшего ARM7TDMI, а перейти на Cortex-ы то вообще открываются невиданные перспективы.

Но разговор про юзабилити.
Т.е. я не услышал, что голые хардварные счетчики как-то можно без изменения сорсов и других софтварных ухищрений применить для профайлинга.
Т.е. способом иным как это предложили для ARM-ов.
bzzz77
Цитата(AlexandrY @ Mar 7 2011, 21:53) *
Это ничего не меняет! Не счетчики же он профилирует. Счетчики могут выполняться хоть тыщу тактов.
Он эти счетчик враз может сделать по прерываниям в ARM-е.
Демон же у TC не вызывает никакого отторжения.


хорошо, покажите мне счетчик обращений ядра к sdram. с меня спасибо и респект.

к слову, oprofile *никакого* измения в исходники/бинарники не вносит. потому что все, что делает oprofile - считывает счетчики. это можно и самому спокойно сделать.
sergeeff
Цитата(bzzz77 @ Mar 7 2011, 21:45) *
я разве сказал "сделано неправильно"? уже читайте, а не додумывайте.


Имеющий уши - да услышит.

Напоследок, утомили вы меня. Ваши слова

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


Finito!
sasamy
Цитата(sergeeff @ Mar 7 2011, 22:22) *
Напоследок, утомили вы меня. Ваши слова
Finito!


2sergeev - да никто вам не мешает воткнуть осциллограф - расслабьтесь, пользуйтесь на здоровье sm.gif Вообще забудьте что тут говорили, вы - самый лучший.
aaarrr
Цитата(bzzz77 @ Mar 7 2011, 22:02) *
хорошо, покажите мне счетчик обращений ядра к sdram. с меня спасибо и респект.

Если все же вернуться к нашему барану - LPC2478, то ситуация с работой SDRAM чуть менее чем полностью очевидна: так как кэш отсутствует, для случайного доступа она практически непригодна, но зато ее можно использовать для буферизации всего и вся. Каких-либо специальных инструментов для изучения ее поведения тоже не нужно, достаточно почитать документацию и потратить пару-тройку часов на написание тестовых программок, если уж сильно захочется. LPC2478 - это весьма маленький процессор, не нужны ему счетчики.
bzzz77
Цитата(aaarrr @ Mar 7 2011, 22:31) *
Если все же вернуться к нашему барану - LPC2478, то ситуация с работой SDRAM чуть менее чем полностью очевидна: так как кэш отсутствует, для случайного доступа она практически непригодна, но зато ее можно использовать для буферизации всего и вся. Каких-либо специальных инструментов для изучения ее поведения тоже не нужно, достаточно почитать документацию и потратить пару-тройку часов на написание тестовых программок, если уж сильно захочется. LPC2478 - это весьма маленький процессор, не нужны ему счетчики.


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


ps. процессору счетчики точно не нужны. счетчики могут быть нужны разработчику
aaarrr
Цитата(bzzz77 @ Mar 7 2011, 22:54) *
...нужно потратить время на тесты типа "кладем вот эту структуру в sram - меряем, теперь повторим для другой структуры"

Зачем решать задачу с конца? Сразу кладем все со случайным доступом в SRAM, буферы - в SDRAM. А вот если SRAM не хватает, тогда только нужно начинать думать, перекладывать и тестировать.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.