Быстрые машины, медленные машины

Да, такого я не ожидал. Записал пару неказистых видосов за пять минут, опубликовал в треде Twitter, а они завирусились, набрав к моменту подготовки статьи 8,8K лайков. В самом деле не мог такого спрогнозировать, учитывая, что я годами вывешиваю только такой контент, который интересен лично мне… и ничего, отклик почти нулевой. Теперь, когда ситуация поостыла, время навести суету и с известной тщательностью изложить возникшие у меня мысли.

В общем, речь идёт о следующих двух видео в треде Twitter: одно записано на старом компьютере с Windows NT 3.51, а другое — на новом с Windows 11. В каждом из двух видео я открывал и закрывал терминал командной строки, файловый проводник, Блокнот и Paint. Сразу видно, что на старом компьютере приложения открываются мгновенно, тогда как на новом компьютере демонстрируют существенный лаг при загрузке. Я задумался: а в чём же компьютеры становятся лучше, если даже такие тривиальные вещи явно регрессировали. И — раз! — посыпались лайки и расшаривания. Конечно, кому-то мои заявления показались надуманными, но абсолютное большинство аудитории согласилось, что проблема действительно существует.

Для затравки повторю мой тезис: наблюдается ужасная задержка в современных компьютерных интерфейсах, работающих с современными ОС и приложениями, и эта задержка усугубляется. Это касается и смартфонов. В то же время, хотя пользовательские интерфейсы в компьютерах прошлого были гораздо отзывчивее, сами эти компьютеры во многих отношениях никуда не годились. Новые системы значительно изменили всю нашу жизнь. Так что же получается?   

Исходное сравнение

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

В исходном видео со сравнением были показаны:

·         AMD K7-600 с 128 МБ ОЗУ и жёстким диском на 5400 об/мин, с операционной системой Windows NT 3.51. Это была машина из 1999-2000 года, а стоявшая на ней ОС была лет на 6 старше. С тех времён компьютерное железо развивалось по-настоящему быстро, в особенности это касается скорости работы ЦП, и от вас как бы ожидалось, что либо вы угонитесь за этим конвейером обновлений с периодом 2 года, либо готовы терпеть невероятную тормознутость. При этом у той машины с избытком хватало мощности для работы с установленной на ней операционной системой.

Напомните мне, какими темпами мы продвигаемся. На этом видео — машина примерно из 2000 года (600 МГц, 128 МБ ОЗУ, винчестер — крутильный ржавый), работает на нём Windows NT 3.51. Обратите внимание: приложения заводятся с пол-оборота.   👇 pic.twitter.com/YEO824vIqI

— Julio Merino (@jmmv) June 22, 2023

·         Машина Surface Go 2 с процессором Intel Core m3, 8 ГБ ОЗУ, винчестер — твердотельный, на нём работает Windows 11. Этой машине 3 года, покупалась она с Windows 10, но Windows 11 на ней официально поддерживается, то есть нас лукаво склоняют на обновление. Эту машину ни по каким меркам не назовёшь мощной, но, во-первых, она буквально воспроизводит опыт работы с Microsoft, а во-вторых, должна же она быть гораздо мощнее системы K7, разве нет? Отовсюду слышим, что любой компьютер или телефон сегодня на порядки более мощный, чем машины, использовавшиеся в прошлом.

Теперь попробуем открыть одни и те же приложения под Windows 11 на Surface Go 2 (четырёхъядерный процессор i5 с частотой 2,4 ГГц, 8 ГБ ОЗУ, твердотельный диск). Всё страшно тормозит. pic.twitter.com/W722PNEGv0

— Julio Merino (@jmmv) June 22, 2023

Да, кстати, в том оригинальном твите я немного переврал спецификацию железа. Вот как я допустил ошибку: погуглил “Surface Go 2” и оказался на странице с данными по ноутбуку: “Surface Laptop Go 2”, скопировал увиденное там и даже не заметил, что допустил неточность.

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

Сравнение получше

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

·         Windows 2000 на машине K7-600 (см. тред об установке). Это ОС из 1999 года, работающая на железе того же года. И, если вам интересно моё мнение, это была лучшая версия Windows всех времён; суперчистый пользовательский интерфейс на ядре NT, полностью оснащённый для производительной и стабильной работы (если не считать ужасно долгой загрузки). Как видите, в том, что касается отзывчивости пользовательского интерфейса, дела на старых машинах шли очень хорошо.

Если кому-то показалось, что сравнение было нечестным — вот Windows 2000 на той же машине с частотой 600 МГц. И железо, и софт одного и того же года выпуска: 1999. Обратите внимание, что оперативность отклика на уровне и с тех пор не ухудшилась. pic.twitter.com/Tpks2Hd1Id

— Julio Merino (@jmmv) June 23, 2023

·         Windows 11 на Mac Pro 2013 (см. инструкции по установке) с 6-ядерным процессором Xeon E5-1650v2, частота 3.5 ГГц, 32 ГБ ОЗУ, двойным графическим процессором и твердотельным диском, который может работать на скорости до 1ГБ/с. Конечно, этой машине уже 10 лет, и в настоящее время используются более современные ОС. Но, пожалуйста, теперь ваш ход. Скажите мне как на духу: каким образом железо, соответствующее таким спецификациям, не может открывать без задержки тривиальные приложения для рабочего стола? Жду.

Кстати, ещё один момент. Да, да, Surface Go 2 не слишком мощный, соглашусь с вами к вашей радости. Но взгляните на это видео. Те же шаги, проделанные на шестиядерном Mac Pro @ 3.5 ГГц с 32 ГБ ОЗУ. Все приложения кэшированы. Обратите внимание, как они отрисовываются фрагмент за фрагментом. Дело не в анимации или посредственном аппаратном обеспечении. pic.twitter.com/9TOGAdaTXO

— Julio Merino (@jmmv) June 23, 2023

Я пользовался Mac Pro потому, что на настоящий момент это лучшая машина с Windows, что есть в моем распоряжении. Фактически, гоняю её ежедневно. Но, повторю: меня не очень беспокоит, что при прогоне этого сравнения на «старой» машине данные могут получиться «неточными». Ещё в прошлом году, когда я ушёл из Microsoft, я регулярно пользовался ПК Z4, изготовленным в 2022 году — с четырёхъядерным i7 ThinkPad на максималках с 32 ГБ ОЗУ, а также ноутбуком i7 Surface Laptop 3 с 16 ГБ ОЗУ. Разумеется, на этих машинах задержки были короче, но взаимодействия в интерфейсе всё равно заметно тормозили.

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

Как развивались компьютеры

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

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

Также мы значительно продвинулись по части ввода/вывода. В стареньких системах дисковый ввод/вывод всегда был слабым местом. Дискеты работали ненадёжно и медленно. CD и DVD были чуть надёжнее, но тоже работали медленно. Жёсткий диск оказывался узким местом сразу по ряду показателей: со временем производительность винчестеров в единицу времени улучшилась; стало возможно редактировать видео в режиме реального времени и т.п., но произвольный ввод/вывод упирался в физические рамки. А именно от скорости произвольного ввода/вывода в основном зависит отклик настольного ПК.

Потом — бум! — появились твердотельные диски, и их стали устанавливать на ПК. Они стали прорывом, так как исправили проблему со случайным вводом/выводом. Внезапно загрузка компьютера, запуск огромной игры, открывание каталогов с кучей мелких фотографий, да и просто работа с компьютером… всё это очень сильно улучшилось. Сложно объяснить всю величину этого прогресса в юзабилити, если вы сами не прожили этого перехода, и страшно видеть, как все эти достижения уже почти утрачены… подробнее об этом ниже.

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

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

Жуткая задержка

Но… ни одно из этих достижений не может оправдать той мучительной тормознутости, которая сегодня наблюдается при работе с пользовательскими интерфейсами. Старое железо из 1999 года, на котором остановлена ОС того же года, демонстрирует, что когда-то отзывчивые системы действительно существовали. Выше я описал массу аппаратных достижений; логично, что они должны были бы улучшить ситуацию, а не ухудшить, разве нет?

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

И... вот ещё что? Тем, кто говорит: «да это же высокое разрешение в 4K!» или «зато какая красивая анимация!» или «А какой приятный фон у рабочего стола!» отвечу: нет, не в этом дело. Взгляните, при отключении всех этих опций задержка всё равно присутствует. В конце концов… скоро напишу об этом пост. pic.twitter.com/9BQy6IpK6a

— Julio Merino (@jmmv) June 26, 2023

Сегодня повсеместно распространены GPU, и именно они принимают на себя это бремя, освобождая ЦП от работы с графикой. Графическую анимацию такого рода, что отрисовывается на обычном ПК, вычислять очень просто. Это доказано macOS со времён возникновения: все графические эффекты на ПК с macOS кажутся мгновенными. Но из-за эффектов взаимодействия действительно замедляются, особенно на это влияет переключение анимации на ПК, как же я эту штуку ненавижу. Но задержки, как правило, связаны с паузами, целенаправленно расставленными в анимации. Если эти эффекты провоцируют задержки из-за того, что GPU с ними не справляются, например, при подключении 4K-дисплея к какому-нибудь старому Маку, то до боли очевидно, что здесь анимация будет буксовать из-за недостатка мощности. Но последнего случая ни в одном из вышеприведённых видео я не встречал; поэтому думаю, что анимация никак не связана с беспокоящими меня вещами.

Поэтому, пожалуйста, давайте критически об этом задумаемся. Как способность одновременно редактировать множество 4K-видеопотоков в режиме реального времени или возможность стримить 4K-фильм может быть связана с замедлением запуска таких приложений как Блокнот? Или контекстного меню на рабочем столе? Или замедлять почтовый клиент? Мы приобрели новые возможности ценой значительного усиления ЦП и GPU, но они не должны портить производительность задач, в сущности, связанных с вводом/выводом. Простое приложение не должно открываться медленнее, чем 20 лет назад; правда не должно. Но ситуация именно такова. Причины задержек на ПК обусловлены чем-то другим, и у меня есть предположения, чем. Но сначала давайте рассмотрим пару примеров.

Примеры

В сфере Windows есть два очевидных примера, которые я очень хотел привести и, в частноти, были упомянуты в том треде в Twitter:

·         Блокнот вплоть до недавнего времени был нативным приложением и открывался практически мгновенно. После того, как его переписали в виде UWP-приложения, ситуация стала быстро портиться. Разница между «до» и «после» здесь очевидна и, всё-таки… приложение по-прежнему такое же лаконичное, как и раньше. Поэтому пользователю явно неприятно от того, насколько Блокнот замедлился.

·         Что касается Терминала Windows, сейчас он выглядит красивее, чем любая из более ранних версий, но теперь эта программа явственно тяжелее, чем старая Командная Строка. А если добавить до кучи PowerShell, то речь идёт уже о нескольких секундах: столько времени  нужно подождать, прежде, чем новое окно командной строки будет готово к работе, если только вы не работаете на суперклассном железе.

У macOS дела действительно идут получше, чем у Windows,  но и у Мака есть свои проблемы. См. этот пример, предложенный @AlexRugerMusic. Даже на могучем M1 возникают проблемы при необходимости открыть приложение с системными настройками:

Вот ещё  пример:

Слева: 2006 MBP (2 ГГц Core 2 Duo, 2 ГБ DDR2 ОЗУ, Max OS X 10.6.8; твердотельный диск).

Справа: MacBook Air 2021 года (M1, 16 ГБ ОЗУ, macOS 13)

Приложения открываются примерно вдвое быстрее, чем на Pro, равно как и на Air (большинство приложений, а не только системные настройки). pic.twitter.com/PjMX1DI4uz

— rewgs (@AlexRugerMusic) June 27, 2023

Вероятно, из всех операционных систем Linux наименее подвержен таким проблемам, и на современном аппаратном обеспечении по-прежнему бегает шустро. Например, дистрибутив Fedora Linux 38, выпущенный в апреле 2023, очень хорошо бегает на микро-ПК одиннадцатилетней давности, даже если по меркам тех лет Gnome или KDE казались обжорами. Тем не менее, это всего лишь иллюзия. Как только вы попробуете установить там какое-либо современное приложение, которое не разрабатывалось конкретно под Linux… оно сразу начнёт тормозить при загрузке и в целом покажет плохую производительность.

Боковой сюжет, но также считаю нужным сказать: сильнейший шок такого рода я испытал в 2009 году, когда пришёл работать в Google. В те времена поисковик Google и гуглопочта GMail развивали космическую скорость и были примерами для подражания. А изнутри компании… поразительно, какими тихоходными были все инфраструктурные инструменты и в особенности внутрикорпоративные инструменты для работы с командной строкой. На самом деле, я виню Google за то, в какой ситуации мы сегодня оказались. Ведь они с их эпичными внутренними системами и стремлением создавать веб-приложения любой ценой и привели нас к той ситуации, о которой речь пойдёт далее…

Причины

Как же всё это случилось? Легко свалить всю вину на раздувание кода, но эта вещь плохо поддаётся дефиниции, так как раздувание бывает и оправданным: одному кажется, что код разбух, а другому — нет. В конце концов, «80% пользователей применяют всего 20% того софта, который устанавливают (см. Принцип Парето), но главный вывод из данной закономерности в том, что эти 20% у разных пользователей отличаются. Поэтому разбухание не обязательно свойственно софту, обрастающему фичами; оно обусловлено другими причинами.

Итак, ещё у нас есть фреймворки и уровни абстрагирования, которые, кажется, раздувают код просто так. Но я не уверен, что эта точка зрения корректна; абстракция необязательно приводит к замедлению функций — посмотрите хотя бы на Rust. Процессы замедляются из-за расстановки приоритетов. Никто больше не ставит производительность во главу угла, за исключением тех случаев, где она абсолютно важна (видеоигры, перекодировка видео и т.п). Сегодня люди (и компании) предпочитают экономить время разработчика. Например: возможно, вы не захотите использовать Rust, так как кривая обучения в нём очень крута. Таким образом, программисту придётся тратить на обучение больше времени, чем на полезную работу. С другой стороны, увеличение времени  компиляции приводит к тому, что вам придётся дольше ждать, пока код скомпилируется, чем сдавать готовый продукт отлаживать его перед продом. Ещё пример: возможно, вам не захочется разрабатывать нативные приложения, так как это означает «двойную работу», и вы решите воспользоваться кроссплатформенным веб-фреймворком, например Electron.

Знаю, легко наговаривать на Electron, но есть очень характерные признаки, что именно эта платформа в значительной степени провоцирует задержку, наблюдаемую при работе с приложениями для ПК. Возьмём, к примеру, 8-ю версию 1Password, на которую многие пользователи перешли с седьмой несмотря на то, как медленно работает новый интерфейс. Либо возьмём Spotify, где с самого зарождения продукта приоритет отдавался скорости запуска и воспроизведения, а сегодня, как знаете, эти показатели ухудшились:

Версия 2009 года: полностью нативное приложение для cocoa размером 20 МБ, запускается менее чем за секунду, мгновенная реакция при щелчке по треку, воспроизведение обычно начинается не более чем за 50 мс. pic.twitter.com/Enzi40PDCX

— Rasmus Andersson (@rsms) May 10, 2023

Эти приложения были переписаны на Electron, чтобы унифицировать работу с ними на ПК и сократить расходы… но для кого это делалось? Сэкономили компании, владеющие продуктами, а не пользователи. Такую экономию ежедневно оплачивает своими нервами каждый из нас, а вдобавок мы вынуждены без необходимости обновлять софт. Пару таких переписываний, плюс сам факт, что ОС не позволяют переиспользовать тяжеловесный фреймворк сразу во множестве приложений (здесь мы возвращаемся к тому, почему использовать всю RAM в качестве кэша — порочная позиция)… и  раздувание кода нарастает ещё быстрее, если вы пытаетесь пользоваться этими приложениями параллельно.

Если оставить в стороне Electron, есть, пожалуй, и другое решение, способствовавшее нарастанию таких задержек. Речь о том, что на вооружение массово берутся управляемые и интерпретируемые языки. Я знаю, что и это легкая цель для упрёков, но эти упрёки оправданные. Возьмём, к примеру, Java или .NET: несколько приложений для Windows постепенно переписали на C#, и, хотя я и не могу этого доказать, имеющийся опыт не оставляет сомнений, что именно поэтому они стали так тормозить. Среды JDK и CLR отлично справляются со своей работой по оптимизации долгоиграющих процессов (например, JIT и PGO с данными в реальном времени), но обеспечение быстрого запуска за минимум времени не их сильная сторона. Именно поэтому, например,  Bazel порождает фоновый серверный процесс, чтобы замаскировать таким образом задержку при запуске, а Android проходит через множество итераций AOT-компиляции. (Примечание автора: должны быть и другие причины, которые я подробно не исследовал. По замечанию одного читателя, я ошибаюсь, утверждая, что новый терминал Windows написан в основном на C#.)

Подробнее эту ситуацию характеризует Закон Вирта.

Единичный качественный скачок легко сходит на нет

Закончу эту статью в пессимистическом ключе и вернусь к тому, как развивается аппаратное обеспечение.

В частности, твердотельные диски обеспечили нам качественный скачок (трансформацию). Обычные винчестеры совершенствовались годами, но так и не позволили поднять произвольный ввод/вывод на такой уровень работы на ПК, отдачу при котором можно было бы назвать молнменосной. С переходом на твердотельные диски ситуация принципиально улучшилась. К сожалению… этот прорыв достался нам единожды: никакая из последующих технологий не обеспечила такой мгновенной трансформации. Следовательно, достоинства этой технологии оказались быстро съедены безответственным подходом к разработке ПО, и мы практически вернулись к тому, с чего пришли. Да, твердотельные диски ускоряются, но новые модели уже не обеспечивают такого разительного роста, как переход с HDD на SSD.

Как вы можете убедиться, работать с новейшими версиями Windows или macOS без SSD практически невозможно. Эти системы изначально рассчитаны на то, что будут устанавливаться на компьютер с твердотельным диском, и такой расчёт обоснован, но влечёт все те проблемы, которые я обрисовал выше. То же самое касается «раздувания» кода приложений: откройте ваш любимый монитор ресурсов, посмотрите график использования дискового ввода/вывода и запустите любое современное приложение. Увидите, как мегабайты за мегабайтами станут грузиться с диска в память, и пройдёт немало времени, прежде, чем это приложение начнёт отзываться. Именно такое разбухание привносит Electron, и на твердотельном диске это приемлемо. Но при более грамотном проектировании можно было бы вообще избежать таких издержек.

Поэтому меня особенно беспокоит Apple Silicon. Вспомните весь пафос по поводу выхода M1 на рынок, вспомните, как превозносили производительность этих машин, а также срок службы батареи  и полностью бесшумные кулеры. Давайте подождём и увидим: вдруг все эти достоинства тоже окажутся обнулены, если мы продолжим двигаться всё тем же безответственным путём. Возможно, опять будет слишком поздно. Технически очень сложно нарастить производительность существующих приложений, а поставить в приоритет при работе в организации почти невозможно.

Итак… смогут ли IT-архитекторы спасти нас, предложив новый революционный технологический переход? Я бы на это не рассчитывал. Не потому, что пути к такому переходу может не найтись, а потому, что лучше бы он вообще не потребовался.