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




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

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

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

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

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



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

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



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

Что за 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

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



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



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

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

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

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

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

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





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




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

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

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

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

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

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

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