Практически любая «оптимизация кода», выполняемая компилятором, который вычисляет ответ быстрее, чем неоптимизированный код, является «энергосберегающей».(Как заметил другой автор, избежать промахов в кэше - большая победа).Таким образом, реальный вопрос заключается в том, «какие оптимизации явно предназначены для экономии энергии по сравнению с сокращением времени выполнения?»(Примечание: некоторые «оптимизации» уменьшают размер занимаемого кода (путем абстрагирования последовательностей кода в подпрограммы и т. Д.; Это может на самом деле стоить больше энергии).
Необычная, которую я не видел ни в одном компиляторе, меняется представление данных.Оказывается, что стоимость хранения / передачи нулевого бита отличается от стоимости хранения одного бита.(Мой опыт работы с TTL и CMOS «ноль» более дорогой, потому что они реализованы в виде аппаратного обеспечения как своего рода «активное понижение напряжения» через резистор от источника питания, в результате чего поток тока, таким образом, нагревается, тогда как «единицы»реализуется, позволяя сигналу «плавать высоко» через одно и то же опускание).Если имеется смещение, то следует реализовать программный код и данные, чтобы максимизировать количество однобитных, а не нулевых бит.
Для данных это должно быть относительно просто сделать.См. этот документ для очень хорошего обзора и анализа ценности, найденной в памяти;он содержит несколько замечательных диаграмм.Общая тема: Большое количество областей памяти занято членами небольшого набора различных значений. Фактически, только очень небольшое количество значений (до 8) занимает до 48% ячеек памяти , часто представляющих собой очень малые числа (в некоторых программах показано, что значительная доля передачи данных предназначена для небольших значений, например, от 0 до 4, причем ноль является, по существу, наиболее распространенным значением). Если нули действительно дороже хранить / передавать, чем единичные, небольшие общие значения предлагают хранить значения в их формате, дополняющем их .Это довольно простая оптимизация для реализации.Учитывая, что значения не всегда являются наименьшими натуральными значениями N, можно заменить N-е наиболее частое значение в памяти на N и сохранить дополнение N, выполнив поиск фактического значения ближе к процессору.(Автор статьи предлагает аппаратный кэш «повторного использования значений», но это не оптимизация компилятора.)
Это немного сложно организовать для программного кода, поскольку набор команд определяет, что вы можете сказать, и обычнонабор команд был разработан независимо от каких-либо измерений энергии.Тем не менее, можно выбирать разные последовательности команд (это то, что делают оптимизаторы) и максимизировать их на один бит в потоке команд.Я сомневаюсь, что это очень эффективно для обычных кодов набора команд.Когда-то, конечно, можно было бы поместить переменные в местоположения, адрес которых имеет большое число, равное одному биту, и предпочитать использовать регистры с более высокими числами, а не с более низкими (на x86 EAX - это двоичный регистр-номер 000, а EDI - регистр № 111)настолько, чтобы спроектировать набор команд в соответствии с частотами выполнения команд, назначая код операции с большими числами в один бит для часто выполняемых команд.