Оптимизация использования памяти

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

Давным-давно, на заре восьмидесятых, когда только-только появились первые IBM PC и MS DOS, Биллом Гейтсом была сказана фраза “640 килобайт хватит каждому”.

Сегодня над этим принято смеяться, однако давайте разберёмся, был ли Гейтс не прав или просто цифровое потреблядство современного общества достигло таких масштабов, что даже обычный калькулятор в состоянии простоя использует в 30 раз больше памяти (19,3 Мб)

И тут возникает вопрос, откуда такие цифры, ведь на компьютерах в далёком 1981 году были по сути те же вычислительные операции и они даже и близко не требовали столько памяти.

С другой стороны, я попробовала посчитать, сколько должна весить одна фотография. Для примера возьмём стандартный HD-формат 1920 на 1080 точек. Для определения цвета каждого пикселя современные компьютеры используют палитру, в которой каждый цвет определяется шестизначным 16-разрядным числом. По 2 цифры на красный, зелёный и синий цвета, сочетание которых может дать любой другой. Вот, например, как это выглядит в фотошопе:

Для того, чтобы закодировать один символ, достаточно одного одного байта. Так как для описания цвета используется 6 символов - каждая точка состоит из 3 байт памяти. Умножим это число на количество точек в фотографии HD-формата и получим 6 220 800‬‬ байт, округлим до 7 миллионов, ведь файл фотографии содержит не только изображение, но и дату создания, разрешение, название и прочую информацию - этого вполне должно хватить. Однако в реальности такие изображения занимают в среднем 300-400 тысяч байт, но уж точно не 7 миллионов. И тут я что-то совсем запуталась - с одной стороны память используется более чем рационально, с другой - максимально нерационально. В чём же подвох?

Дело в том, что не совсем корректно ставить в один ряд 2 этих примера. Фотографии это информация, а калькулятор это программа. Данные и приложения используют память по-разному. Но всё же данные это делают куда более рационально. То, как я описала хранение изображения больше всего похоже на формат RAW или как его ещё называют “сырой” формат файлов изображения. В реальности же мы обычно храним фотографии в JPEG или PNG форматах.

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

В отличие от RGB в нём 2, а не 3 цветоразностных компоненты - синяя и красная

Кроме того, при переводе в JPEG выполняется, так называемое, “прореживание” - простыми словами это сжатие, при котором каждая область 2х2 пикселя приобретает среднее значение цвета, только за счёт этого файл уже сжимается в 4 раза. По этой же причине JPEG плохо подходит для хранения изображений с резким контрастом между соседними пикселями, например чертежей или текстов. Яркость изображения в данном формате и вовсе является одинаковой для каждой области 8х8 пикселей. Именно поэтому при масштабировании или цветокоррекции изображений мы можем видеть характерные артефакты возле контуров объектов.

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

Каждая из цифр хранится в памяти как двоичный код. Например, шестёрка это 0110 - целых 4 бита памяти. Причиной тому двоичность наших устройств. Компьютер определяет каждый бит данных как 1, когда сигнал есть, или как 0, когда сигнала нет. Но если бы наши компьютеры использовали, например, 16-разрядную систему счисления, то, в зависимости от уровня напряжения, в каждый бит можно было бы записывать и двойку, и тройку, и любую другую цифру до 16ти. Грубо говоря, когда процессору приходит сигнал с напряжением 2 вольта, он интерпретирует это как двойку, 3 вольта - как тройку и так далее. В таком случае нам бы потребовалось всего 6 бит памяти, чтобы описать каждый пиксель - в 4 раза меньше, чем требуется сейчас. И это если говорить о сыром формате фото. JPEG-файлы в таком случае вообще бы весили по 20-30 килобайт. Но, к сожалению, в те времена, когда люди создавали многоразрядные компьютеры, они никак не могли справиться с помехами - любой, даже незначительный скачок напряжения приводил к сбоям, к тому же были и остаются очень большие сложности при описании многоразрядной машинной логики. Ну а сейчас двоичные компьютеры захватили мир и внедрить что-то настолько инновационное крайне тяжело, ведь почти все данные, которые мы используем двоичны - новые компьютеры просто не смогут их правильно интерпретировать. Хотя не исключаю, что когда человечество упрётся в физический предел производительности, исследования возможностей многоразрядных, хотя бы троичных, компьютеров возобновятся.

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

А вот таблицы троичной логики были разработаны ещё в СССР во время разработки компьютера “Сетунь”, который своим ядром использовал, как раз-таки, троичную логику. В своё время “Сетунь” превосходил по мощности иностранных конкурентов, но не разбирающееся советское правительство свернуло проект. А теперь уже из США слышатся мнения, что неплохо бы попробовать сделать компьютер на троичной уравновешенной системе счисления, так как она многое упростит. Например, профессор Стэнфордского университета Дональд Кнут говорил о том, что троичная логика элегантнее и эффективнее двоичной и не исключает того, что в будущем компьютеры будут работать по большей части на ней. И если так действительно произойдёт, то я всерьёз задумаюсь о том, что люди, утверждающие, что проблема не в сложности технологий, а в том, что миром правит рынок, правы. И над тем, что ничего не мешало за пару лет уменьшить техпроцесс со 180-90нм в начале 2000-х до 14-7нм, которые имеем сейчас, а растягивалось это лишь с целью иметь стабильную прибыль на протяжении десятков лет. Это, конечно, теории заговора, но внедрять передовые устройства, когда ещё можно заработать на старых, действительно не выгодно, не удивлюсь, если где-нибудь уже знают на десятки лет вперёд, какие технологии и в каком порядке выпускать на рынок. Вот только вместо быстрого движения мирового прогресса их будут тонким слоем размазывать на десятилетия.

Что же касается использования памяти программами, то тут стоит понимать, что программирование это целое искусство, а оптимизация это отдельная его ветка. Но всерьёз заниматься ей начинают только тогда, когда ресурсов компьютера реально не хватает. Если же программа требует 20 мегабайт оперативной памяти, хотя можно оптимизировать до 10, скорее всего делать этого никто не будет - ведь нам доступны гигабайты памяти, разницы всё равно никто не заметит. Но да, это можно считать, как я выразилась, “цифровым потреблядством”, я реально не знаю, на что калькулятор тратит столько памяти

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

И творцы этого нелёгкого дела даже организовали собственный конкурс-фестиваль, на котором делятся друг с другом успехами - “The 64k contest”. На нём можно увидеть всё что угодно - 3D-анимацию, игры, программы, компиляторы...да только между принимающими в нём участие шахматными программами ежегодно устраивают отдельный турнир. А правило всего одно - размер работы не должен превышать 64 килобайт. И если вы думаете, что это выставка творений уровня приставки Денди, то очень сильно ошибаетесь.

Полностью трёхмерным музыкальным клипом с музыкой и словами там уже никого не удивишь. Гении оптимизации придумывают самые изощрённые способы уменьшить размер своих работ.

Немецкая игра “.kkrieger” 2004 года - отличный пример того, как именно разработчикам удаётся использовать так мало места. Графика в ней выглядит примерно на уровне Doom 3, при этом Дум занимает несколько гигабайт памяти, а .kkrieger всего 96 килобайт. Вся фишка в том, что в игре не хранятся файлы текстур или их код - в ней записаны лишь правила, по которым текстуры должны сами процедурно генерироваться. Если бы их хранили в классическом виде, то одни только файлы текстур весили бы не менее половины гигабайта. Вышесказанное относится не только к текстурам, буквально всё в игре генерируется при её старте - освещение, формы, анимации, звуки. Кроме того, для ещё большего сжатия, разработчики применили алгоритм фрактального шифрования. То есть при наличии желания и таланта, несколько гигабайт вполне себе можно уместить в 96 килобайт памяти. Разработчики “.kkrieger” не исключают того, что их концепцию в будущем будут использовать ААА-игры, ведь процедурная генерация текстур в теории позволяет создать текстуры тем лучше, чем более мощный компьютер для этого используется.

Однако пока что это всё мечты и текстуры хранятся в папке с установленной игрой. К сожалению, далеко не всегда даже современные игры могут похвастаться хорошей оптимизацией. Например, игры RUST и Escape From Tarkov сделаны на одном и том же движке. При этом RUST летает на большинстве даже не очень мощных компьютеров, а Тарков даже на моём стримерском железе порой выдаёт не более 20 кадров в секунду. И причиной тому, наверняка, плохая оптимизация. Эту фразу очень часто можно услышать при обсуждении современных компьютерных игр. Что же такое оптимизация? Если кратко, то это процесс убирания ненужного. Например, внутренние полигоны моделей или их части, расположенные там, где игрок их не видит. Если их не убрать, то они всё равно будут просчитываться, тратя на себя ресурсы компьютера. А внешне разница будет незаметна, ведь эти элементы расположены там, где пользователь их не видит. Ещё одним примером является оптимизация света или так называемые прожоги. На просчёт динамического освещения тратится немало видеопамяти. Однако, во многих местах можно убрать источник динамического освещения и просто нарисовать белое пятно, как будто от источника света. Называется это прожогом. Эффект примерно одинаковый, но прожоги тратят значительно меньше ресурсов вашего компьютера (Примеры прожога и динамического света есть в моём YouTube-видео). В общем-то, как и было сказано, оптимизация это целое искусство - различных способов сделать игру легче огромное множество. Это и уменьшение текстур, и упрощение алгоритмов, и изменение отрисовки объектов на различной дистанции и многое, многое другое. Стоит также заметить, что оптимизация зачастую зависит не от таланта разработчиков, а от их добросовестности.

Если же вернуться к главному вопросу этой статьи - “Рационально ли используется память современными приложениями и данными”, то ответить на него однозначно невозможно, ведь прогресс всё время движется вперёд. Как вы видели из примеров хранения изображений - вроде бы всё максимально рационально. Однако если появятся компьютеры, использующие другие технологии, а они уже есть, то можно оптимизировать процесс хранения данных ещё сильнее. Думаю, пройдут тысячелетия, прежде чем люди найдут оптимальный во всех смыслах способ хранить информацию, если такое вообще будет.

Спасибо всем, кто подписывается и отдельное спасибо тем, кто поддерживает через Patreon. Пишите в комментариях ваши предположения зачем калькулятору столько оперативной памяти. До скорого!