Кто-нибудь знает компилятор, который оптимизирует код для потребления энергии для встроенных устройств?

Ответ 1

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

Изменить: в FOSDEM была беседа о Анализе потребления энергии в LLVM.

Ответ 2

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

Необычный, который я не видел в любом компиляторе, меняет представление данных. Оказывается, что стоимость хранения/передачи нулевого бита отличается от стоимости хранения одного бита. (Мой опыт работы с TTL и CMOS - "ноль", являются более дорогими, потому что они реализованы в аппаратных средствах как своего рода "активное вытягивание" через резистор из питания, что приводит к тому, что поток течет таким образом, что "одни" являются реализуется путем пропускания сигнала "плавать высоко" через тот же pull down). Если есть предвзятость, тогда необходимо реализовать программный код и данные, чтобы максимизировать количество бит, а не нулевые.

Для данных это должно быть относительно просто. См. этот документ для очень хорошего обзора и анализа ценности, найденной в памяти; он содержит некоторые довольно красивые диаграммы. Общая тема. Большое количество мест памяти занято членами небольшого набора различных значений. Фактически, только очень небольшое число значений (до 8) занимают до 48% мест памяти, часто очень маленькие (в некоторых программах для некоторых программ значительная часть данных переносится для небольших значений, например, От 0 до 4, причем нуль является по существу самым общим значением). Если нули поистине дороже хранить/переносить, чем одни, то небольшие общие значения предполагают сохранение значений в их формате дополнения. Это довольно простая оптимизация для реализации. Учитывая, что значения не всегда являются наименьшими N естественными, можно заменить N-е наиболее частое значение в памяти на N и сохранить дополнение к N, выполняя поиск фактического значения ближе к процессору. (Автор статьи предлагает аппаратное "повторное использование значения", но это не оптимизация компилятора).

Это немного сложно организовать для программного кода, так как набор инструкций определяет, что вы можете сказать, и обычно набор команд был разработан независимо от любых измерений энергии. Тем не менее можно было выбрать разные последовательности команд (что делают оптимизаторы) и максимизировано для одного бита в потоке команд. Я сомневаюсь, что это очень эффективно при использовании обычных кодов команд. После того, как вы, конечно, могли бы помещать переменные в адреса, адрес которых имеет большое количество бит, и предпочитают использовать регистры с более высокими номерами, а не более низкими (на x86, EAX - двоично-регистрационный номер 000, а EDI - номер регистра 111). чтобы создать набор команд в соответствии с частотами выполнения команд, назначая код операции с большим числом бит на часто выполняемые инструкции.

Ответ 3

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

Снижение тактовой частоты - это, пожалуй, самая большая вещь, которую вы можете сделать, чтобы сократить потребление энергии. И сделать столько, сколько вы можете, это самый простой способ снизить тактовую частоту. Например, использование DMA по явным прерываниям позволяет алгоритмической обработке заканчиваться за меньшее количество циклов. Если у вашего процессора есть странные режимы адресации или параллельные инструкции (я смотрю на вас, TMS320), я был бы удивлен, если бы вы не могли сократить время выполнения жестких циклов для того, чтобы удвоить текущий ток, давая чистую экономию энергии. И в семействе процессоров Blackfin, снижение тактового сигнала позволяет снизить напряжение ядра, значительно уменьшая потребление энергии. Я полагаю, что это верно и для других встроенных процессоров.

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

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

Ответ 4

Попробуйте " MAGEEC". У меня нет непосредственного опыта компилятора. Но в описании на веб-сайте говорится, что можно генерировать энергоэффективный код.