Найти в Дзене
Сделай игру

Размер и быстродействие софта

Оглавление

Размер операционной системы Windows 3.11 составлял 16,3 мегабайта; размер операционной системы Windows 11 требует 64 Гигабайта. Потребности в памяти и быстродействии процессора также сильно выросли. Минимальные системные требования возросли очень существенно, при этом практически не добавив ничего качественно нового (тут вы со мной, разумеется, можете не согласиться). При этом не секрет, что часть ресурсов идёт на обратную совместимость с прежними версиями операционной системы.

И если вы думаете, что это проблема Microsoft, то нет, это проблема современного программного обеспечения.

Битва суперов: инженеры против менеджеров
Битва суперов: инженеры против менеджеров

Крошечная ОС

Между тем, на сегодняшний день существуют операционные системы, которые вполне умещаются на дискету 3,5 дюйма и занимают всего 1,44 мегабайта: вот например. Да, у неё есть свои проблемы и свои изъяны, но, всё же, это полноценная операционная система столь малого размера, что его можно не учитывать в рамках статистической погрешности. Про её быстродействие не стану ничего писать, не так много программ для неё созданы, но она существует.

Демосцена на 64 кб

А есть, к слову, и настоящее состязание, в котором разработчики создают небольшие программки, которые разворачиваются в демосцены - просто показ каких-то изображений. Размер исполняемого файла не должен превышать 64 килобайта, однако то, что вы там увидите - вероятней всего вас поразит. Можете заглянуть сюда, если хотите впечатлиться мастерством отдельных разработчиков.

Бочка мёда и ложка дёгтя

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

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

Hello, world!

Если написать программу, выводящую одну фразу на C++ и собрать её безо всяких оптимизаций компилятора - то мы получим файл размером 8,3 килобайта, что, по современным меркам - вообще пустяк. Если после этого мы откроем файл посредством objdump (я сейчас пишу про ELF-файлы в среде GNU\Linux, собранные при помощи gcc), то увидим довольно много дополнительной информации. Например, секции с данными, которые не используются в программе, но нужны компилятору.

Что внутри у файла, собранного при помощи gcc
Что внутри у файла, собранного при помощи gcc

Не находите, довольно много всего для приложения, которое должно вывести всего лишь одну фразу?

Но не будем останавливаться на достигнутом. Давайте соберём точно такую же программу при помощи FASM (flat assembler) и посмотрим не её размер: 229 байт. При этом, никакой лишней информации

Это всё, что отдал мне objdump
Это всё, что отдал мне objdump

Разница в объёме - почти в 40 раз, результат - одинаков. И тут ещё мы не работали с быстродействием, а ассемблер имеет возможность ускорить некоторые вычисления.

Скорость или скорость?

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

Выходит, в какой-то момент встаёт вопрос: а чего мы хотим больше, скорости разработки или скорости быстродействия?

Ответ на этот вопрос сказал мне один из моих прежних работодателей, когда я предложил одну довольно жирную (и долгую в изготовлении) оптимизацию, которая сильно ускоряла поиск:

- А сколько ты будешь это делать?
- Ну, примерно месяц, может больше
- А не, тогда не надо...
- Почему?
- Потому что дешевле новый сервер поставить и всё заработает быстрее

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

Мир, который мы допустили

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

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

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

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

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

Заключение

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

Размышляя над этим, не могу отделаться от мысли, что пойди мы по пути высокой эффективности, быстродействия и оптимизации, то не исключено, что развитие компьютеров и программно-аппаратной периферии застыло бы где-то на уровне 90-х годов прошлого века: простой интернет, простые текстовые редакторы, простые операционные системы. Мы бы много чего могли бы не увидеть: смартфоны, потоковое видео, современные игры... список продолжите сами. Так что не исключено, что концентрация усилий не на качестве софта, а на его массовости - создали положительный прецедент, позволив нам приобщиться к тому миру ИТ, который мы сейчас знаем.

А может быть, мы бы всё равно к этому миру пришли, но всего было бы меньше, с качеством выше. Кто знает. А вы что думаете на этот счёт?