что такое зеленый код
Как создавать «зеленый» код
Что такое энерго-эффективность в применении к мобильным платформам? Простыми словами это возможность сделать больше, затратив при этом меньше энергии.
Каждому пользователю хотелось бы как можно реже заряжать свое мобильное устройство, будь то смартфон, нетбук, ультрабук. Возможно, когда-нибудь наступит момент, когда устройство нужно будет зарядить всего один раз, после его покупки и пользоваться до тех пор пока оно не надоест или морально не устареет.
Если рассмотреть укрупненую модель любой мобильной платформы то она состоит и 3-х основных частей.
Аккумулятор
Является хранилищем энергии мобильного устройства. Производители аккумуляторов каждый год стараются увеличить емкость, уменьшить время полной зарядки.
Железо
Является основным прямым потребителем энергии. Тут прогресс тоже не стоит на месте. Производители «железа» создают все более энерго-эффективные чипы, выдающие большую производительность на Ватт потребленной энергии, добавляют различные режимы энергопотребления, позволяющие отключать неиспользуемое железо, переводить в режимы низкого энергопотребления, экономя тем самым батарею.
Является косвенным потребителем энергии. Напрямую софт ничего не потребляет, он вынуждает железо потреблять энергию. Здесь тоже есть свои методики, позволяющие продлить жизнь батареи. О проблеме энерго-эффективности софта я и хотел бы поговорить в данной статье.
Как именно софт влияет на потребление энергии? Если в двух словах — он не дает железу «спать».
Рассмотрим одного из крупных потребителей энергии в системе — процессор.
Процессор может управлять своим энергопотреблением с помощью, так называемых, C-State. Для тех, кто не знаком с этими режимами, привожу короткую справку:
С0 — рабочее состояние процессора, подразделяется на различные P-States.
C1 — состояние, когда процессор ничего не делает, но готов приступить к работе, правда с небольшой задержкой. Многие процессоры имеют различные вариации этого состояния.
С2 — почти тоже самое, что и С1, но в этом состоянии процессор потребляет меньше энергии, и имеет большую задержку для перехода в рабочее состояние.
С3 — состояние «сна», переходя в это состояние процессор очищает кэш второго уровня. Характеризуется меньшим энергопотреблением, и более долгим временем перехода в рабочее состояние.
… и так далее в зависимости от процессора.
Для того чтобы было более наглядно приведу иллюстрацию:
Самый энерго-эффективный вариант — процессор всегда спит. Значит самая эффективная, в плане энергозатрат программа, это та программа, которая не запущена и его не «будит». Она не производит никаких действий, и вообще ничего не потребляет. Но такой софт никому не нужен, программа должна делать что-то полезное. Компромисное решение — программа, которая не делает ничего тогда когда не должна ничего делать («будит» только по нужде), и если делает что-то, то делает это максимально быстро.
Особенно это касается программ, которые выполняют какие-либо действия в фоновом режиме. Эти программы должны спать всегда и просыпаться только при наступлении какого-либо события.
События рулят или Event-driven подход
Приведу пример «неправильного» кода (к сожалению, такой подход к написанию кода используется гораздо чаще, чем вы думаете). Данный пример кода служит для получения и данных из сокета, например, в каком-нибудь серверном приложении.
Что же здесь «неправильного»? Есть данные или нет данных, код будет «будить» процессор каждые 1000 мс. Поведение кода напоминает осла из Шрека: «Уже приехали? А теперь приехали? А сейчас приехали?».
«Правильный» код, для данной задачи, не будет ни кого спрашивать, он уснет у будет ждать когда разбудят его. Для этого, во многих операционных системах, существуют объекты синхронизации, такие как события. С учетом сказанного код должен выглядеть так (код не полный, опущена обработка ошибок и кодов возврата, моя задача просто проиллюстрировать принцип):
В чем прелесть примера выше? Он будет спать тогда, когда ему нечего делать.
Таймеры, будильники нашего кода
Иногда без таймеров не обойтись, примеров масса — проигрывание аудио, видео, анимация.
Немного о таймерах. Интервал системного таймера Windows, по умолчанию, равен 15,6 мс. Что это означает для программ? Допустим вы хотите, чтобы выше приложение выполняло какое-то действие каждые 40 мс. Проходит первый интервал в 15,6 мс, слишком мало, проходит второй 31,1, опять рано, третий 46,8 — попали, таймер сработает. В большинстве случаев лишние 6,8 мс не имеют значения.
Так же прямое влияние на Sleep, если вы вызовете Sleep(1), при установленном интервале в 15,6 мс, то спать код будет не 1 мс, а все 15,6 мс.
Но если дело касается проигрывания видео — тогда это поведение не приемлемо. В этих случаях разработчик может изменить дискретность системного таймера вызвав функцию из Windows Multimedia API — timeBeginPeriod. Данная функция позволяет изменить период таймера вплоть до 1мс. Для кода это хорошо, но сильно сокращает жизнь батареи (вплоть до 25%).
Как найти компромисс? Все просто изменяйте период системного таймера только тогда, когда это действительно необходимо. Например, если вы разрабатываете приложение, использующее анимацию и вам нужна меньшая дискретность таймера меняйте таймер тогда, когда анимация отображается и происходит, и возвращайте если, например, окно свернуто или анимация остановлена.
С точки зрения пользователя иногда, чтобы понять как продлить жизнь от батареи будет интересна утилита Powercfg. С ее помощью можно узнать какое-то приложение изменило период системого таймера, значение периода системного таймера, информацию о проблемах драйверов, не позволяющих переводить «железо» в режим низкого энерго потребления и т.д.
Объединение таймеров
В Windows 7 появилась замечательная возможность объединять таймеры. Что это такое и как это работает представлено на рисунке ниже:
Т.е. Windows «подстраивает» таймеры приложений таким образом, чтобы они совпадали со срабатываниями таймера самой операционной системы.
Для того, чтобы использовать эту возможность необходимо вызвать
Полное описание функции вы можете найти в MSDN. В рамках данной статьи нас интересуют только параметр TolerableDelay, который определяет максимальное допустимое отклюнение от заданного интервала.
Более подробно о таймерах в Windows можно прочитать в статье Timers, Timer Resolution, and Development of Efficient Code
Сделай это быстро
Еще один способ сделать программу более энерго-эффективной это научить ее делать нужные вещи быстро, на сколько это возможно. Добиться этого можно, например, оптимизировав код, путем использования SSE, AVX и других аппаратных возможностей платформы. В качестве примера хочу привести использование Quick Sync в Sandy Bridge для кодирования и декодирования видео. На сайте Tom’s Hardware можно посмотреть результаты.
Допустим мы оптимизировали нашу программу, но насколько она теперь более энерго-эффективна, как это оценить? Очень просто — с помощью специальных программ и инструментов.
Инструменты для анализа энерго-эффективности
1. Intel Power Checker. Пожалуй самый простой и быстрый способ оценить энерго-эффективность своей программы.
Обзор и описание программы можно найти в блоге ISN
Более сложный, но вместе с тем более информативный инструмент, служит для отслеживания различных активностей железа и софта, которые влияют на время работы от батареи.
Тоже достаточно интересный инструмент, определяющий энергопотребление различных компонентов платформы. Может работать в связке с ваттметром WattsUp.
Где узнать больше
Intel Power Efficiency Community статьи, практические рекомендацие и советы по созданию энерго-эффективного программного обеспечения.
Battery Life and Energy Efficiency сборник статей и рецептов от Microsoft
Timers, Timer Resolution, and Development of Efficient Code ссылка уже приведена выше, для тех, кто начинает читать статью с конца.
Если есть вопросы — задавайте в комментариях. Также свои вопросы по разработке «зеленого» софта можете задать мне на вебинаре, который состоится завтра, 15 декабря в 11 утра.
Green Code и березки. Основные принципы зеленого кода в разработке
Всем привет. Меня зовут Стас, в компании Домклик я курирую разработку сервисов бек-офиса для ипотечного кредитования Сбербанка.
В последнее время во всевозможных докладах и подкастах я довольно часто стал встречать термин «Green Code». Покопавшись в интернете и изучив эту тему, я понял, что этим термином описывают комплекс приёмов в разработке и проектировании приложений, позволяющих сократить энергопотребление оборудования, на котором этот код выполняется.
Более-менее этим вопросом обычно озадачиваются разработчики мобильных приложений, в основном потому, что устройство, на котором будет выполняться их код, имеет ограниченную емкость батареи.
Тема стала достаточно «хайповой», и я решил прикинуть, как именно принципы «зеленого» могут быть отражены в WEB-разработке.
Основные принципы написания «зеленого кода»
Прочитав достаточно много докладов и статей на эту тему, я бы выделил следующие аспекты разработки приложений, которые влияют на энергопотребление:
1) Упрощение и оптимизация алгоритмов
Как уже было сказано выше, выполнение кода должно приводить к минимальному потреблению энергии. Оптимизированный код будет выполняться быстрее и, соответственно, потребует меньше затрат на его обработку и охлаждение оборудования.
Давайте попробуем посчитать разницу в энергозатратах на исполнение конкретной операции в коде — классической сортировке списка. Я специально буду утрировать ситуацию в приведенном примере, чтобы контрастнее показать разницу.
Возьмём сортировку методом пузырька. Наверное, это один из самых неоптимальных способов. Очень нам подходит. Рассчитаем сортировку списка и посмотрим, как она отразилась на энергозатратах MacBook. Для начала смоделируем массив данных и саму логику сортировки пузырьком:
Для замера влияния исполнения кода на энергозатраты я использовал систему мониторинга iStat Menus 6 (https://bjango.com/mac/istatmenus/). Подключил MacBook к сети, закрыл все сторонние приложения, выждал определенное время для зарядки батареи, и запустил сортировку:
График энергопотребления при выполнении сортировки пузырьком:
Виден ярко выраженный скачок потребления мощности длительностью в 305 секунд. Он вызван исполнением нашего неоптимального запроса. Дополнительно потраченная энергия за 5 минут (305 секунд):
Теперь допустим, что этот код случайно попал на промышленный продуктовый сервер (примем как допущение, что дополнительные энергозатраты на сервере будут такими же, как на моем MacBook, и зависимость прямо пропорциональная) и стал выполняться с частотой 1 раз в 10 секунд. Тогда в год мы получим дополнительные энергозатраты:
Предположим, что ЦОД, в котором размещается сервер, получает энергоснабжение от котельной, в качестве топлива в которой используется березовая древесина. При сгорании 1 м 3 березовой древесины выделяется 1900 кВт*ч/м 3 энергии. Разумеется, КПД котельной не 100 %, и если принять его за 75 %, то получим:
Если принять дерево за правильный цилиндр, объем которого равен
где R — радиус ствола дерева, примем его за 0,12 метра (среднее значение),
H — высота ствола дерева, примем ее за 3 метра (среднее значение).
V = 3,14 × 0,0144 × 3 = 0,14 м 3
График энергопотребления при выполнении стандартной сортировки в Python:
Применяя ту же логику расчета (длительность пика была 10 сек), получаем:
P = (W2 – W1) × 10 сек = (3,51 [мощность при выполнении скрипта] – 2,9 [мощность в состоянии покоя]) × 10 сек = 6,1 Дж = 0,0000016 кВт*ч
В год получим (при условии выполнения операции 1 раз в 10 секунд)
365 дней × 24 часа × 3600 с/10 × 0,0000016 кВт*ч = 5,05 кВт*ч
5,05 / 1900 / 0,75 × 7,14 = 0,025 бревна березы.
Конечно, в этом примере много допущений, да и сортировку пузырьком делают достаточно редко. Но полученные числа показались мне интересными
2) Использовать событийную модель (event driven model) работы приложения там, где только можно
Дело в том, что большинство процессоров поддерживают несколько «состояний» энергопотребления. В том случае, если ядро не занято какими-то вычислениями, операционная система переводит его в состояние «сна», при котором процессор потребляет гораздо меньше энергии.
Спектр состояний (оптимизация по энергопотреблению):
Подробнее об этом можно прочитать тут.
Довольно часто бывает ситуация, когда какая-то логика приложения должна выполниться при возникновении определенного события. И чтобы узнать, что это событие произошло, заинтересованный в получении этой информации сервис зачастую периодически опрашивает сервис, хранящий факт выполнения этого события. По таймеру. Причем подавляющая часть запросов получает отрицательный ответ, то есть 99 % запросов, по сути, не нужны.
Правильно было бы транслировать соответствующее событие в очередь, и считывать факт его возникновения всем заинтересованным сервисам.
Спектр состояний (оптимизация по энергопотреблению):
Другой пример — взаимодействие фронтенд- и бекенд-компонентов приложения. Если фронту надо поменять свое состояние в зависимости от данных в базе, иногда на бекенд периодически шлют запросы, создавая ненужную дополнительную нагрузку. Хотя можно проинформировать фронт об изменении состояния необходимых данных через сокет–сервер.
Хотя с сокетами тоже можно ошибиться, вот пример «плохого» кода:
Видно, что даже если данные в сокет не поступили, всё равно каждые 1000 секунд код будет выполняться, тратя драгоценную энергию.
То же самое можно написать чуть по-другому, и энергии будет тратиться меньше:
3) UI/UX: Интерфейс пользователя не должен показывать «лишние» данные
Если данные всё же используются, но редко, то лучше их не отображать по умолчанию, а показывать только по кнопке «Показать детальную информацию».
Простой пример, иллюстрирующий этот принцип: отображение списков объектов данных (заявок, пользователей, торговых точек, складов, офисов) при условии, что сценарий использования формы всё равно предполагает поиск нужного объекта.
Пример плохого интерфейса:
На странице отображается огромный список задач (разбитый на «страницы»), однако пользователь всё равно будет искать определенного клиента (по определенной логике у него в голове) в поисковой строке сверху. Зачем тратить ресурсы на получение списка задач?
Тот же самый сценарий, реализованный по-другому:
Пример «зеленого» интерфейса:
Логика выбора клиента перенесена в систему, по умолчанию не запрашивается лишних данных «по привычке». Этому варианту, помимо экологов, и кибербезопасность будет люто аплодировать.
4) Рефакторинг
Рефакторинг полезен почти всегда. Но в этом контексте он нужен для одной простой цели: выкинуть ненужный (мусорный) код или упростить существующий, чтобы снизить энергопотребление.
Многие приложения, развивающиеся более трёх лет, накапливают в себе сотни строк неиспользуемого или непрогнозируемо работающего кода, оставшегося от ранее реализованных (и уже, возможно, выпиленных) функций. Иногда этот код даже исполняется, но результат его работы не востребован.
Периодический аудит и рефакторинг снизят количество такого кода, хотя, вероятно, избавиться от него до конца не получится.
К примеру, регулярно рефакторя один из наших сервисов (в рамках технической квоты рабочего времени), мы обнаружили вот такое:
Всё это можно убрать без потери функциональности.
5) Использовать низкоуровневые языки программирования для высоконагруженных приложений
Очевидно, что в большинстве случаев приложения, написанные на низкоуровневых языках, более энергоэффективны. Нагруженный сервис на Python (если он выполняет простую операцию) имеет смысл переписать на C/C+. Будет быстрее и «зеленее».
Правда, часто у нас нет нужных знаний для написания логики на таких языках.
6) Группировать I/O-операции
Системы хранения, как и процессоры, также имеют различные состояния энергопотребления.
В режиме «сна» потребляется гораздо меньше энергии, чем в рабочем «прогретом» состоянии. Особенно это характерно для систем хранения/жестких дисков.
Если в работе приложения можно группировать данные, записываемые на диск, и обращаться к диску не постоянно, а в определенные периоды времени, то это будет энергоэффективнее, поскольку в период «простоя» операционная система отправит диск в «спячку».
7) Использование менее энергоемких систем хранения для логов
Хорошей практикой будет использовать «горячее» и «холодное» хранение. Например, логи за последнюю неделю имеет смысл хранить в индексированном виде «горячего» приготовления, поскольку вероятность обращения к ним будет достаточно высока. Логи за более длительный период можно хранить в более дешевых и менее энергозатратных системах хранения.
А как в промышленном масштабе?
Выше мы рассмотрели основные приемы работы с кодом для обеспечения его энергоэффективности. Но даже соблюдение большинства этих правил даст весьма скромную экономию, которую сложно будет визуализировать. Конечно, если в проде не сортировать списки методом пузырька
Гораздо больший эффект даст целенаправленная разработка функциональности по внедрению электронного документооборота.
Одним из направлений деятельности команд Домклик является оптимизация и упрощение процесса получения ипотеки. И в этом ипотечном процессе на финальной стадии готовится достаточно много документов на бумаге. Причем в нескольких экземплярах. Один экземпляр для продавца, один для покупателя, один для архива банка.
Мне приятно осознавать, что Домклик тратит много усилий для изничтожения этой порочной практики и перевода всего документооборота в электронный формат. В этом году значительная часть ипотечных сделок была уже полностью оцифрована (печаталась только одна бумага: заявление на выпуск УКЭП, усиленной криптографической электронной подписи). Все остальные документы подписывались уже этим УКЭП и бумага на них не тратилось.
Благодаря этой инициативе было сэкономлено уже более 67 491 108 листов бумаги. В березках это примерно 23 000 деревьев!
Цифровой код здоровья. Где и в каком виде уже используется
В конце ноября 2020 года китайский лидер Си Цзиньпин предложил создать международный код здоровья. По мнению инициатора, внедрение такого механизма могло бы решить проблему запрета на перемещения людей в условиях пандемии коронавируса. Предложение Си Цзиньпина вызвало бурную реакцию в социальных сетях. Попробуем разобраться, что такое код здоровья и где он уже применяется в мире? Может ли помочь восстановлению туризма после пандемии? И животрепещущее – примут ли систему международных кодов?
📲 Где сегодня используется код здоровья
В Китае коды здоровья приобрели повсеместное распространение с весны 2020 года. Каждый китайский город создал свою систему в социальных сетях, а жители для получения кода обязаны зарегистрироваться в ней и указать персональные данные, включая номер удостоверения личности.
Код здоровья – это QR-код, который выдается гражданам после того, как они ответят ряд вопросов:
За недостоверную информацию граждане могут понести уголовную ответственность, поэтому отвечают честно.
Зеленый – значит, здоров?
На основании предоставленных сведений лицо получает красный, желтый или зеленый код здоровья:
Без кода здоровья не пустят в супермаркет, жилой комплекс или автобус, человек не сможет посетить музей или поужинать в ресторане. На входе в любые учреждения дежурят охранники, проверяющие коды здоровья. Даже если у пользователя есть зеленый код, но телефон сядет в неподходящий момент и показать код не получится, в общественные места вход будет закрыт.
При получении кода здоровья в Китае не проверяются результаты теста на коронавирус или анализа на антитела. При выдаче анализируется только наличие контактов с заболевшими коронавирусом, а также посещение эпидемиологически неблагоприятных провинций. То есть гарантий того, что человек с зеленым кодом не болеет коронавирусом, нет. В свою очередь, наличие желтого кода говорит о том, что человек представляет потенциальную угрозу из-за своих контактов и поездок, но сам он может не болеть коронавирусом.
Но при наличии зеленого кода человек не должен находиться в изоляции или на карантине. Он может посещать общественные места.
Вправе ли иностранцы получить код здоровья, и будет ли он действовать в других странах
Иностранцы, которые постоянно проживают в Китае, обязаны получить код здоровья. Но для иностранных граждан из других стран такой код не имеет смысла. Он не признается другими странам в качестве гарантии здоровья и не позволяет добиться снятия ограничений на поездки.
Более того, даже при выезде в другую провинцию в Китае нужно получать новый код.
🛩 Международные QR-коды. Влияние на туризм
По предложению Си Цзиньпина, которое он озвучил на ведущем форуме международного сотрудничества по наиболее важным аспектам международной экономической и финансовой повестки дня (G20), предполагается создание признаваемых всеми странами QR-кодов, которые будут выдаваться на основании тестов на коронавирус.
Введение международных кодов призвано помочь восстановлению туризма после пандемии и производственных цепочек – чтобы не возникало перебоев с поставками запчастей, как сейчас, на момент написания статьи – декабрь 2020 года. В случае внедрения данных кодов сведения будут загружаться в единую систему.
Но кто будет отвечать за разработку данной системы, как будут признаваться коды другими странами, и как будет обеспечиваться защита персональной информации, не до конца понятно. Пока высказанная инициатива имеет статус предложения и никак не тестируется.
Аналоги в мире
Весной в ЕС активно обсуждался вопрос о введении паспортов здоровья в Германии, Италии и Греции. Предполагалось снимать некоторые ограничения в плане передвижения после того, как человек переболеет коронавирусом. Но потом оказалось, что коронавирус не дает стойкого иммунитета, и многие заболели повторно, поэтому от идеи паспортов на этом основании отказались.
В Европе и Америке тестируется свой вариант паспортов здоровья CommonPass. Это пропуск для пассажиров, позволяющий им передвигаться по миру, не соблюдая карантин в 14 дней. Подобные паспорта уже действуют на рейсах Великобритании.
Паспорта здоровья выдаются на основании тестов на коронавирус, которые были сданы в сертифицированных лабораториях. Полномасштабное внедрение запланировано на 2021 год.
В России
Похожие технологии уже применяются и в России. Так, в Москве владельцам общественных мест рекомендовали внедрять QR-коды и SMS-оповещения для посетителей. Перед этим обязательные коды в ноябре 2020 года ввели в ночных клубах, а также правительственных зданиях, префектурах и управах.
Система уже тестируется в спортивных школах и на спортивных объектах. В ближайшее время коды планируется внедрить на предприятиях общественного питания, в сфере услуг и торговли.
В России коды здоровья работают так:
То есть предъявлять код на входе в общественные места нет необходимости, если только вход не контролирует представитель организации.
💫 Проблемные и положительные моменты международных цифровых кодов
Предложение о внедрении международных цифровых кодов вызвало противоречивую реакцию в мировом сообществе. Часть людей увидела в ней способ решения проблемы международного туризма и восстановления мировой торговли. Другие посчитали коды здоровья первым шагом к «цифровому рабству» и покушением на личные свободы и права.
В качестве положительных моментов от возможного внедрения кодов здоровья можно отметить то, что в Китае данная система сыграла немаловажную роль в решении проблемы с заболеваемостью коронавирусом: в то время как в мире началась вторая волна пандемии, в Китае ситуация остается более менее стабильной. Число случаев заражения за время пандемии не превысило 90 тысяч человек, а число смертей за последние месяцы не менялось. Система кодов здоровья позволила не допустить новые вспышки заболеваемости при локальных случаях заражения. Например, в июне, когда на крупнейшем оптовом рынке Пекина были выявлены случаи заболевания коронавирусом, система позволила выявить не только всех заболевших сотрудников, но и покупателей. Им пришлось соблюдать некоторое время самоизоляцию, но распространение болезни удалось сдержать.
Среди проблемных точек внедрения международных цифровых кодов можно отметить следующие:
С учетом того, сколько разногласий сегодня имеется между странами, и как остро стоит вопрос доверия, можно полагать, что систему международных кодов вряд ли примут.
❓ Часто задаваемые вопросы
При получении кода здоровья не нужны результаты анализа на коронавирус, при получении паспорта здоровья или иммунного паспорта – нужны.
В России его применяют только в Москве в ночных клубах и правительственных учреждениях. В Китае он обязателен на всей территории страны.