Энергоэффективное программное кодирование

Question

В типичном портативном / переносном встраиваемом системном устройстве срок службы батареи является основной проблемой при проектировании H / W, S / W и функций, которые может поддерживать устройство. С точки зрения программирования, известно о коде, оптимизированном для MIPS, памяти (данных и программ). Я знаю о режиме глубокого сна H / W, режиме ожидания, который используется для синхронизации оборудования на более низких циклах или поворота часов до неиспользуемых циркулирующих каналов для экономии энергии, но я ищу некоторые идеи с этой точки зрения :

Где мой код работает, и он должен продолжать выполняться, учитывая, как я могу эффективно написать код "power", чтобы потреблять минимум ватт?

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

Существуют ли какие-либо программные соображения по проектированию высокого уровня, которые следует учитывать при проектировании структуры кода или при проектировании низкого уровня, чтобы сделать код максимально энергоэффективным (наименее энергоемким), насколько это возможно?

Answer 1

• Как сказал 1800 INFORMATION, избегайте опроса; подписаться на события и ждать, пока они произойдут
• Обновлять содержимое окна только при необходимости - пусть система решит, когда его перерисовать
• При обновлении содержимого окна убедитесь, что ваш код воссоздает как можно меньше недопустимого региона
• С быстрым кодом ЦП быстрее возвращается в режим глубокого сна, и есть большая вероятность того, что такой код останется в кеше L1
• Одновременная работа с небольшими данными, поэтому данные также остаются в кэшах
• Убедитесь, что ваше приложение не выполняет никаких ненужных действий в фоновом режиме
• Сделайте ваше программное обеспечение не только энергоэффективным, но и энергосберегающим - обновляйте графику реже, когда работаете от батареи, отключайте анимацию, меньше перебивает жесткий диск

И прочитайте некоторые другие рекомендации . ;)

Недавно в блогах Intel Software появилась серия публикаций под названием "Оптимизация программных приложений для Power" . Может быть полезным для разработчиков x86.

Answer 2

Zeroith, используйте полностью статическую машину, которая может останавливаться во время простоя. Вы не можете победить ноль Гц.

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

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

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

Не доверяйте инфраструктурам графического интерфейса, которые вы не проверили на наличие кода «спи и крутись». Особенно таймер событий, который вы можете использовать для # 2.

Блокировать поток при чтении вместо опроса с помощью select () / epoll () / WaitForMultipleObjects (). Делает нагрузку на планировщик потоков (и ваш мозг), но устройства обычно работают нормально. Это немного меняет ваш дизайн высокого уровня; становится все чище! Основной цикл, который опрашивает все, что вы можете сделать, медленно и бесполезно расходуется на процессор, но гарантирует производительность. (Гарантированно будет медленным)

Кэшируйте результаты, лениво создавайте вещи. Пользователи ожидают, что устройство будет медленным, поэтому не разочаровывайте их. Чем меньше бег, тем лучше. Беги как можно меньше. Отдельные нити могут быть убиты, когда вы перестанете в них нуждаться.

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

Посмотрите на систему реального времени, которая, по вашему мнению, может вам понадобиться. Это экономит время (так) позже. Они лучше справляются с резьбой.

Answer 3

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

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

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

Answer 4

Не опрашивать. Используйте события и другие примитивы ОС для ожидания уведомлений. Опрос гарантирует, что процессор будет оставаться активным и использовать больше времени автономной работы.

Answer 5

Во избежание опроса хорошее предложение.

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

Answer 6

Установите неиспользуемую память или вспышку на 0xFF, а не 0x00. Это, безусловно, верно для вспышки и EEPROM, не уверен насчет S или D RAM. Для выпускных вечеров есть инверсия, поэтому 0 сохраняется как 1 и занимает больше энергии, а 1 сохраняется как ноль и занимает меньше. Вот почему вы читаете 0xFFs после стирания блока.

Answer 7

Ну, в той степени, в которой ваш код может выполняться полностью в кеше процессора, у вас будет меньше активности шины и экономия энергии. Если ваша программа достаточно мала, чтобы разместить код + данные целиком в кеше, вы получаете это преимущество «бесплатно». OTOH, если ваша программа слишком большая, и вы можете разделить свои программы на модули, более или менее независимые от других, вы можете получить некоторую экономию энергии, разделив ее на отдельные программы. (Полагаю, можно также создать цепочку инструментов, которая распределяет связанные пакеты кода и данных в куски размером с кэш-память ...)

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

У Transmeta была идея позволить машине выполнять некоторую оптимизацию команд на лету, чтобы сэкономить электроэнергию ... Но, похоже, это не помогло достаточно ... И посмотрите, откуда они это взяли.

Answer 8

Рассмотрите возможность использования сетевых интерфейсов как можно меньше. Возможно, вы захотите собрать информацию и отправить ее пакетами, а не постоянно отправлять ее.

Answer 9

Проще говоря, делайте как можно меньше.

Answer 10

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

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