что обозначает зеленый код

Что обозначает зеленый код

Что означает зеленый код из «Матрицы». Довольно неожиданно

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

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

Саймон Уайтли, дизайнер кода Матрицы рассказал изданию CNet, что поток кода не является бессмысленным. Весь код состоит из случайных рецептов суши, взятых из кулинарной книги его жены:

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

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

В данный момент готовится новый проект во вселенной «Матрица», но о нем пока ничего неизвестно.

Источник

Как создавался зеленый код в «Матрице»? Вы не поверите!

Видите его, закрывая глаза? Снится ли он вам? Высока вероятность, что если вы видели «Матрицу» в 1999 году, когда вышел фильм, либо позднее, изображение зеленых символов, сбегающих вниз на черном экране, прочно отпечаталось в вашем сознании. Несмотря на тот факт, что впервые этот код появился в фильме с кучей шикарных сцен, он стал одним из самых знаковых символов «Матрицы». Смотрелось круто и отлично резюмировало основную идею шедевра Вачовски: что, если мир — иллюзия? Что, если все запрограммировано?

Что записано в коде «Матрицы»?

Шли месяцы и годы, «Матрица» поросла травой, и люди начали задумываться, откуда же взялся ныне известный «цифровой дождь». И ответ оказался гораздо более увлекательным, чем любая из загадок фильма. В 2017 году CNET сообщил, что этот код был просто… набором рецептов суши.

Саймон Уайтли — продюсер Animal Logic в Австралии. Однако его также называют «человеком, который создал код». Он говорит, что закончил работать над цифровым дождем после того, как Лана и Лилли Вачовски наложили вето на предыдущую последовательность, которую создала команда дизайнеров, работающая над «Матрицей».

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

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

В течение следующих недель Уайтли тщательно разрабатывал и рисовал каждую японскую букву от руки. Затем их доставили Джастину Маршаллу, который сейчас работает художником по визуальным эффектам в Animal Logic, чтобы он оцифровал их и написал код, падающий каскадом по всему экрану. Изначально буквы должны были течь по экрану слева направо, говорит Уайтли, но когда он увидел анимацию, он сказал, что «никаких эмоций она не вызвала».

Уайтли вернулся к источнику. Как и большинство японских текстов, книги рецептов были написаны «задом наперед», а предложения читались сверху вниз. Поэтому Уайтли спросил Маршалла, может ли тот перевернуть код, чтобы он стекал с верхней части экрана — и так родилась история.

«Фильм очень ориентирован на машин», говорит Уайтли. «Мне нравится идея того, что все в этом механическое, но реальный код извлечен из чего-то органического и свободно текущего».

Уайтли удивлен, что знаковый зеленый код «Матрицы» — да и фильм тоже — приобрел такую популярность в последнее время. Он говорит, что его было относительно просто создать.

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

«На самом деле это не книга. Это журнал, но он называется книгой. Большинство японцев слышали о нем, либо имеют на книжной полке».

Уайтли также говорит, что коренные японцы не смогут извлечь рецепт прямо из фильма, потому что цифровой дождь написан кодом. Более того, по его словам, рецепты суши обычно пишутся хираганой и кандзи, то есть слоговыми и логографическими символами, соответственно. Код «Матрицы», с другой стороны, стилизован под катакану, то есть слоговые символы, которые используются при написании иностранных слов.

Интересная история, не так ли? Предлагаем обсудить ее в нашем чате в Телеграме.

Источник

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 деревьев!

Источник

Как создавать «зеленый» код

Что такое энерго-эффективность в применении к мобильным платформам? Простыми словами это возможность сделать больше, затратив при этом меньше энергии.

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

Если рассмотреть укрупненую модель любой мобильной платформы то она состоит и 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 утра.

Источник