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

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

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

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

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

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

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

ну вы хоть приличия ради загляните по ссылке, да? 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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