профилирование и оптимизация на 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. Померить разницу и быть счастливым?

[ViKo]

В Keil есть Analisis Windows, а именно Logic Anilizer, Performance Analizer, Code Coverage. А также трассировка, а также Execution Profiling. И время выполнения можно засечь в отладчике. Сам почти не пользовался, поэтому насколько это соответствует требуемому, не скажу. На мой взгляд, достаточно.

[sasamy]

день добрый,

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

В lpc2478 есть ETM, нужно всего несколько килодолларов чтобы купить jtag с поддержкой ETM trace

[sergeeff]

До чего все любят усложнять себе (и другим) жизнь!

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

[sasamy]

До чего все любят усложнять себе (и другим) жизнь!

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

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

[bzzz77]

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

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

[sergeeff]

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

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

[bzzz77]

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

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

[ar__systems]

Меня тоже неприятно удивило отсутсвие в АРМе каких-либо performance counters.

[aaarrr]

В старших (ARM11, Cortex-Ax) есть.

[sergeeff]

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

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

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

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

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

[scifi]

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

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

[bzzz77]

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

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

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

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

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

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

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

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

[aaarrr]

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

Лучшим инструментом является все-таки головной мозг. Чтобы решить, что положить в SRAM, а что в SDRAM без кэша, нужен именно он, а никак не ETM c PM.

[sergeeff]

не понимаете и ладно.

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

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

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

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

[sasamy]

Как использовать ETM для вылавливания cache miss. Получите наш общий респект и денежку подзаработаете.

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

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

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

[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? И как вы себе представляете постоянное размещение программы в кеше, если объем программы/данных превышают объемы соответствующих кешей?

[ar__systems]

Что за perf counters?
Все серьезные RTOS под микроконтроллеры имеют механизм "Performance Counters"

Это все фуйня. У интела начиная с пентиума есть полноценные железячные счетчики, посмотрите. А все эти "фичи" от операционки -- жалкий эрзац.

[scifi]

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

[ar__systems]

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

Вы продолжаете тупить. В програмее размером 1 Mb (Гхм... компилированного кода? Вы серьезно?) будет небольшое количество критичного кода, и естественно никто никогда ВСЮ программу не профилирует, даже на PC, где 1МБ как раз не предел. Раз уж взялись википедию читать, почитайте про профилирование.

[AlexandrY]

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

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

[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.

[sergeeff]

... если не принимать во внимание особенности CPU.

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

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

[bzzz77]

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

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

не стоит за меня додумывать и пытаться все списать на фанатизм. oprofile и линукс тут не причем. он просто показывает эти счетчики, которые реализованы в cpu. какие счетчики есть - такие и покажет. точно так же работают в базе amd code analyst и intel vtune - вытаскивают эти счетчики. соответственно меня заинтересовали счетчики в arm7tdmi. ну или какие-то другие методы для профилирования на arm. которое, в ряде случаев, сильно помогает.

[AlexandrY]

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

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

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

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

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

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

[sergeeff]

не стоит за меня додумывать

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

Успехов! Счетчик дней начал тикать.

[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-ы.

[bzzz77]

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

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

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

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

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

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

на arm я не пенял. я просто спросил как можно профилировать на arm. в ответ на это вы принялись валить сюда кучу лажи и ничего по существу. извиняйте за прямоту.

[AlexandrY]

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

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

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

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

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

[bzzz77]

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

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

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

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

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

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

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

[sergeeff]

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

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

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

Ну-ну. Философия списывающего школьного двоечника.

[bzzz77]

Ну-ну. Философия списывающего школьного двоечника.

философия "оскорбить когда сказать нечего" ?

[ar__systems]

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

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

[sergeeff]

философия "оскорбить когда сказать нечего" ?

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

[bzzz77]

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

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

[AlexandrY]

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

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

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

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

[bzzz77]

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

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

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


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

[sergeeff]

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

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

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

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

Finito!

[sasamy]

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

2sergeev - да никто вам не мешает воткнуть осциллограф - расслабьтесь, пользуйтесь на здоровье Вообще забудьте что тут говорили, вы - самый лучший.

[aaarrr]

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

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

[bzzz77]

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

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


ps. процессору счетчики точно не нужны. счетчики могут быть нужны разработчику

[aaarrr]

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

Зачем решать задачу с конца? Сразу кладем все со случайным доступом в SRAM, буферы - в SDRAM. А вот если SRAM не хватает, тогда только нужно начинать думать, перекладывать и тестировать.

[bzzz77]

Зачем решать задачу с конца? Сразу кладем все со случайным доступом в SRAM, буферы - в SDRAM. А вот если SRAM не хватает, тогда только нужно начинать думать, перекладывать и тестировать.

уже влазит с трудом, уже usb/eth-ram задействованы. уже буферы для fat в sdram. а функционал еще хочется добавить.

[igorsk]

DMA используется? В LPC имеется поддержка memory-to-memory и scatter/gather трансферов. В декодировании MP3 не очень вижу как это может помочь, но вдруг.

[bzzz77]

DMA используется? В LPC имеется поддержка memory-to-memory и scatter/gather трансферов. В декодировании MP3 не очень вижу как это может помочь, но вдруг.

SG видел, полезная штука. хотел попробовать SG для вывода буферов в DAC. касательно mem2mem не уверен - похоже helix'у важнее иметь временные переменные в sram, а собственно mp3 данные можно положить в sdram без особенной потери в производительности.

[singlskv]

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

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

[bzzz77]

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

там все несколько проще. на каждый счетчик есть счетчик превышения по достижению которого срабатывает прерывание и регистрируется адрес, на котором это случилось. от ОС ничего не требуется. от профайлера - только настроить события, счетчики превышения и регистрировать адреса. ну и потом соотнести эти адреса с функциями-инструкциями. так работает oprofile, а на его основе - amd code analyst. и этого хватает для нормального профилирования.

[sonycman]

уже влазит с трудом, уже usb/eth-ram задействованы. уже буферы для fat в sdram. а функционал еще хочется добавить.

Это вам 90 килобайт оперативки не хватило для MP3 декодера? Откуда такие запросы-то?
Люди вон на 50 килобайтах справляются...

[Rst7]

Это вам 90 килобайт оперативки не хватило ...
Люди вон на 50 килобайтах справляются...

Ололо, давайте померяемся, кому сколько надо

[sonycman]

Ололо, давайте померяемся, кому сколько надо

Ничего смешного не вижу
Сам рассчитываю на 24 килобайта для декодера, плюс буфера для ЦАПа и файловые - в 32 кб надо бы уложиться

[Rst7]

Ничего смешного не вижу

А я не в Ваш огород Я чисто топикстартера, ага