Кармак прав? Почему старые ПК не тянут современные программы

Джон Кармак уверен, что если бы разработчики больше занимались оптимизацией, старые компьютеры могли бы прекрасно справляться с нынешним ПО. Так ли это на самом деле? Размышляет исполнительный директор ALP Group Александр Казеннов.

Недавно Джон Кармак, тот самый гений, который разработал Doom и создал один из самых влиятельных игровых движков — id Tech, выкинул в сеть интересное заявление. В двух словах: по его мнению, нынешняя индустрия ПК живет на апгрейдах «железа», потому что программисты не заморачиваются с оптимизацией кода. На данный момент у твита уже почти 300 000 просмотров, 100+ комментариев, 250+ репостов и свыше 2 000 лайков.

Кармак говорит, что, по сути, большинство людей могли бы продолжать работать на тех устройствах, которые у них были 5–10 лет назад, если бы разработчики ставили на первое место производительность. Вместо этого с каждой новой версией программ мы сталкиваемся с тем, что железо начинает «чихать» под нагрузкой, и мы либо покупаем что-то новое, либо терпим тормоза и баги.

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

Честно — не могу согласиться с выводами Кармака на 100%. Да, все мы замечаем, что иногда современные приложения и веб-сайты начинают притормаживать на старых компьютерах. Но это не только и не столько вина «ленивых программистов» или кривого программного кода. Реальность несколько сложнее.

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

Кроме того, многое зачастую зависит от внешнего окружения: на какой операционке стоит ПО, какая СУБД используется и вообще глобально на каком «железе» всё вертится. Нередки случаи, когда вендоры окружения выпускают обновления, которые ломают работу приложения, опирающегося на это окружение. Никто не в состоянии протестировать все приложения на всех обновлениях операционных систем или баз данных по всему миру. Бывает, что приложение перестает работать потому, что новый процессор перестал поддерживать какой-то из старых наборов инструкций — и это не редкость, поддерживать всё и бесконечно невозможно, особенно в эпоху, когда каждый производитель тянет одеяло на себя.

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

Но если не брать в расчет такие вычурные сайты и системы с использованием искусственного интеллекта на собственных серверах, то, мне кажется, будет лукавством сказать, что старые ПК не тянут современный софт. Положа руку на сердце, большинство отраслевых, офисных и бизнес-приложений без проблем открывается на «железе» 5-, 7- и даже 10-летней давности.

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

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

Подозреваю, что с такой ситуацией сталкивался и сам Кармак. Он действительно создал очень хорошие оптимизированные вещи, но даже у него не всё всегда было гладко. Вспомним выход Doom 3, который был технологическим прорывом с точки зрения графики, но с точки зрения забагованности и соответствующих тормозов — далеким от совершенства.

В общем, пока что мечта Джона о безупречном оптимизированном коде, который «летает» на старом оборудовании, кажется недостижимой. Но нам, как разработчикам, всегда нужно стремиться искать баланс между скоростью вывода решения в продуктив и качеством исполнения.

А вы что думаете? Поделитесь своим мнением в комментариях ⬇