Расчет Mips для встроенного ПО
Меня недавно (и неоднократно) спрашивали клиенты о MIPS, необходимом для запуска нашего программного обеспечения. Обычно мы могли избавиться от этих вопросов, объяснив клиенту, что это действительно зависит от процессора / ОС / hw (наше программное обеспечение очень портативно) и / или варианта использования (то есть от того, как используется наше программное обеспечение).
Но у меня последний не только очень упрямый, но и дает веские причины для этого. :) Ему нужна оценка, потому что он не уверен, что у него достаточно мощности для запуска нашего программного обеспечения, поэтому покупать программное обеспечение до этой оценки нелогично. (Мы не можем предоставить демонстрацию / оценку, поскольку для работы на этой конкретной платформе потребуется значительный объем работы.)
А теперь вопрос: есть ли у кого-нибудь опыт решения такой задачи на какой-либо части hw с каким-либо программным обеспечением? Любой пример из реальной жизни будет действительно полезен. У меня есть возможность запускать наше программное обеспечение на многих ОС и на большом количестве оборудования. Так что, если вы знаете какой-либо инструмент для такой оценки на любом оборудовании, есть шанс, что я смогу его использовать или, по крайней мере, получить представление. Насколько я знаю, я знаю только, как измерить загрузку процессора на ОС eCosPro.
Редактировать:
Использование зонда на самом деле является хорошей идеей, если предположить, что я могу создать среду управления, в которой только мое программное обеспечение выполняет все инструкции, которые я могу считать, мои, и я предполагаю, что у зонда есть интерфейс для этого. На самом деле у меня есть несколько разных аппаратных отладчиков, и если у кого-то есть опыт, как это сделать, будет действительно хорошо, в любом случае я собираюсь прочитать какую-то документацию завтра и, надеюсь, найду что-то в этом направлении.
Ответы 8
У вас есть симулятор или зонд отладчика, который может дать вам количество инструкций? Вам даже не нужно делать это для правильной целевой платформы, достаточно приблизительного подсчета инструкций.
Если все остальное не удается, запустите его на любой платформе, к которой у вас есть доступ, масштабируйте время выполнения, используя частное ваше-МГц / клиент-МГц. Это должно дать вам приблизительную оценку очень того, какое время выполнения будет испытывать заказчик.
У меня нет большого опыта использования различных зондов отладчика, к сожалению, я лишь приблизительно представляю, что с ними можно делать.
В любом случае, спасибо, я опубликую здесь результат после того, как получу его :)
I / S - это «слабый» показатель для системы с операционной системой.
Вкратце, что вам нужно сделать, это
- вычислить наихудший путь выполнения инструкций и подсчитать, сколько циклов требуется для выполнения (это означает чтение сборки для этого ЦП и просмотр справочника ЦП, в котором указано количество циклов).
- Теперь выясните свои ограничения в реальном времени.
- Затем вы используете №1 для циклов наихудшего случая. Отрегулируйте ЦП вверх / вниз, пока он не будет соответствовать ограничениям в реальном времени.
- Добавьте фактор выдумки.
Это очень долгий путь ... :) Программа очень большая и сложная.
Первое, что вам нужно сделать, это придумать какие-то критерии для правильной работы. Это будет во многом зависеть от природы приложения - ваши критерии могут включать «должен выполнить код x за 3 мс» или «должен иметь задержку менее 100 мс». Любой критерий, который не связан с количественным измерением, будет трудным, поскольку он будет субъективным.
Определение ваших критериев правильной работы позволит вам найти критические участки кода. Имейте в виду, что они могут быть обнаружены в угловых случаях, а не при нормальной работе.
Если эти критические части кода небольшие, то инструкции по подсчету для вашей целевой платформы будут относительно простыми. Если у вас есть симулятор, это может быть еще проще. (в зависимости от кода вам может потребоваться сделать макет, чтобы убедиться, что он выполняется, но это, вероятно, все равно будет проще, чем подсчет инструкций, если у вас есть большой кусок кода для анализа)
Если ваш критический код велик, вам, возможно, придется сделать что-то похожее на предложение JesperE. Если ваше приложение не ориентировано на отрасль, чрезвычайно чувствительную к цене, есть вероятность, что заказчик согласится принять небольшую задержку в расчетах - так что лучше переоценить, чем недооценить ваши требования к процессору.
В чем я бы отличался от предложения JesperE, так это в том, чтобы предлагать не концентрироваться на МГц, а, скорее, на фактических MIPS целей. Например, скомпилируйте и выполните свой код на тестовой платформе - если у вас есть профилировщик, это может быть лучше. Затем скомпилируйте свой код для цели клиента и выполните грубое сравнение количества инструкций в результирующем исполняемом файле. Затем вы можете включить это соотношение вместе с относительными MIPS тестового и целевого процессоров при вычислении времени выполнения.
Вы говорите, что ваше программное обеспечение очень портативно, поэтому я предлагаю запускать программное обеспечение на платформе, которая наиболее близка по архитектуре процессора, набору команд процессора и типу памяти / периферийной шины. Измерьте самую длинную процедуру, которая должна выполняться в реальном времени, а затем оцените, как долго она будет работать в их архитектуре.
вопрос был в том, как измерить ... Идея измерения приходила мне в голову :)
1. Переключайте булавку при входе в критическую процедуру и выходе из нее. Используйте прицел на штифте, чтобы измерить время. 2. Настройте компилятор на вывод файлов сборки и подсчитайте строки кода для каждой процедуры, чтобы приблизительно определить количество инструкций.
на самом деле это невозможно, моя кодовая база больше, чем средняя база кода встроенной ОС. Недостаточно найти самую длинную подпрограмму, найти самый длинный путь выполнения более уместно, но технически сложно.
Хорошо, вы понимаете, что это чревато отказами от ответственности и предупреждениями - скорость процессора, скорость памяти, попадания в кеш, сброс таблиц страниц MMU, конкуренция на шине и т.д ... (если это мощная встроенная система) - все это значительно влияет на решение ....
Было сказано, что .... я бы сделал вот что. Получите операционную систему реального времени (оставайтесь со мной), возможно, что-то вроде FreeRTOS (бесплатно, какой сюрприз) или u / C-OS-II (не бесплатно для коммерческого использования, может быть, 3 тысячи долларов). Эти ядра позволяют настроить код для подсчета циклов простоя ЦП (цикл вращения простаивающих задач).
Так что запустите все свое приложение (или приложение клиента) как единственную (не простаивающую) задачу на плате, с которой вы, ребята, согласны (например, плата MPC860, плата ARM7 и т. д.). Измерьте% ЦП на плате через ОСРВ. (например, «на плате Flibber, работающей на частоте 60 МГц, наше приложение использует 12% ЦП»).
Без того, чтобы они давали вам больше или наоборот, это звучит для них довольно разумно.
Хорошо то, что как только вы это сделаете, вы сможете повторно использовать результаты для других целей и / или советов директоров, возможно, цифры помогут вам увеличить продажи и / или настроить / оптимизировать ваше программное обеспечение.
Удачи!
Это кажется разумным приближением.
Это был подход, который я планировал использовать до того, как прочитал пост JesperE. И несмотря на то, что использование процессора кажется мне более актуальной информацией, клиент хочет MIPS, и я постараюсь посмотреть, смогу ли я получить информацию о MIPS от ICE.
Илья - Извините, я не совсем "замкнул цикл" - скажем, на 60 МГц ваш ЦП обеспечивает ~ 50 MIPS .... так что если ваша программа использует 10% ЦП (90% простоя), она использует примерно 10% от 50 MIPS = 5 MIPS.
Конечно, я понимаю это. Мне просто кажется, что зондовый подход является более общим, если, например, я найду способ получить mips от Лаутербаха, я смогу получить информацию о mips на любой платформе, которая имеет ледяной интерфейс, без дополнительного кодирования на каждая ОС (а мы поддерживаем большое количество ОС),
Большинство современных отладчиков дают вам возможность просматривать использованные инструкции, например; РВДС. Кроме того, вы можете использовать эмуляторы процессора, чтобы получить достойное представление об используемых инструкциях, фактически не выполняясь на платформе (если ваш код является автономным, например кодеком или криптографическим модулем, и не зависит от платы) - обратите внимание, что это даст вам инструкции, не циклы. На циклы будут влиять детали вашей платы (например, состояния ожидания, доступ к памяти и т. д.)
На двух архитектурах процессоров, которые я использую (MSP430F5X и AVR32), в процессор встроен регистр счетчика аппаратных циклов. У меня обычно есть схема, в которой, когда процессор не занят, он переводится в состояние ожидания с низким энергопотреблением с остановленным ядром процессора. Затем есть два варианта расчета фактической загрузки процессора. Я могу либо установить точку останова в функции периодического таймера и прочитать количество выполненных циклов процессора, либо я могу инструментировать определенные процессы, читая этот регистр в начале и в конце их работы. Время простоя процессора не отображается в счетчике циклов, поскольку ЦП остановлен на это время.
Вы не указываете архитектуру своего процессора, но такая возможность может присутствовать.
RapiTime утверждает, что может дать вероятностную оценку времени выполнения наихудшего случая для вашей цели. Лично не пользовался, но презентации видел ...
Если ваша цель достаточно похожа на цель вашего клиента, вы, вероятно, сможете масштабировать ее, чтобы оценить WCET на их платформе. Затем они могут сравнить это время с «свободным» временем, которым располагает их нынешняя система.
Отличная идея, знаете ли вы зонд Любые, который может это сделать? Оценка на моей платформе удовлетворит заказчика.