[Перевод] Быстрые машины, медленные машины
Что ж, это оказалось очень неожиданным. Я записал за пять минут пару (первое, второе) простых видео, которые после размещения в Twitter мгновенно стали вирусными и собрали 8,8 К лайков. Такого исхода я не предвидел, учитывая, что я годами публиковал, как мне казалось, интересный материал, который практически не привлекал внимания. Сейчас, когда всё поутихло, пора немного качнуть лодку и порассуждать на эту тему уже более взвешенно.
Вкратце поясню: пост в Twitter содержит два видео — на одном старый компьютер с Windows NT 3.51, а на втором — новый с Windows 11. В каждом ролике я открывал и закрывал командную строку, проводник, блокнот и Paint. Вы можете отчётливо видеть, что приложения на старом ПК открывались мгновенно, притом что на новом их загрузка происходила со значительной задержкой. У меня возник вопрос, как так получается, что компьютеры становятся лучше, но простейшие вещи при этом начинают работать медленнее. И тут «На тебе!», пошёл поток лайков и ретвитов. Очевидно, что некоторые возразили моим утверждениям, но подавляющее большинство людей согласились с тем, что проблема присутствует.
Для начала выскажу своё утверждение: задержка в современных интерфейсах компьютеров при современных ОС и приложениях оказывается ужасной и становится всё хуже. Это также касается смартфонов. При этом несмотря на то, что UI на старых ПК были гораздо отзывчивее, эти компьютеры также имели множество недостатков, и современные системы значительно улучшили нашу жизнь. Какие же тут можно сделать выводы?
▍ Первое сравнение
Начнём с основного. Изначально размещённое мной сравнение было несправедливым, и я это понимал. Тем не менее я знал, что «подобающее» повторение эксперимента будет давать те же результаты, поэтому продолжал работать с тем, что у меня было. Съёмка этих роликов получилась спонтанной, потому что идея разместить твиты возникла лишь когда я загрузил старую машину, кликнул по Command Prompt и офигел от мгновенности запуска приложения.
В первых роликах снимались:
- AMD K7–600, 128MB RAM, 5400 RPM HDD с Windows NT 3.51. Это машина из 1999–2000-х годов с операционной системой примерно на 5 лет её старше. В те времена аппаратное обеспечение переживало период активного развития, особенно по части быстродействия процессоров, и вам приходилось либо делать каждые два года апгрейд, либо сталкиваться с серьёзными тормозами. Это я к тому, что данная машина сильно превосходила своей производительностью использованную ОС.Видео
- Ноутбук Surface Go 2: Intel Core m3, 8GB RAM, SSD с Windows 11. Это машина трёхлетней давности, которая поставлялась с Windows 10, но Windows 11 на ней официально поддерживается — и, как вы понимаете, это уловка, подталкивающая вас к апгрейду. Этот ноутбук никак не назовёшь производительным, но: во-первых, он обеспечивает полноценный опыт работы с Microsoft и, во-вторых, он должен быть намного мощнее системы AMD K-7, ведь так? Нам постоянно напоминают, что любой компьютер или телефон сегодня обладает на порядки большей мощностью в сравнении с машинами прошлого.Видео
Ах да, в оригинальном твите я указал ошибочную спецификацию железа. Ошибка получилась так: я забил в Bing запрос «Surface Go 2» и зашёл на страницу «Surface Laptop Go 2», откуда и скопировал информацию, не обратив внимание на её неточность.
Все приложения до этого открывались, значит, должны удобно располагаться в RAM.
▍ Более точное сравнение
Очевидно, что разные люди заметили в моём сравнении недочёты (несправедливое соотношение аппаратного обеспечения, ошибочная спецификация), поэтому я повторил эксперимент, когда твит начал набирать популярность.
- Windows 2000 на машине K7–600 (читайте описание установки). Это операционная система из 1999 года, работающая на железе из того же года. И лично я считаю, что это была лучшая версия Windows за всю историю: суперчистый UI на ядре NT, имеющий всю функциональность, которую вы могли пожелать, при высокой производительности и стабильности (за исключением длительной загрузки). Как видите, в плане отзывчивости UI у этой старой машины всё по-прежнему очень хорошо.Видео
- Windows 11 на Mac Pro 2013 (описание установки) с 6-ядерным Xeon E5–1650v2, 3.5GHz, 32GB RAM, двумя GPU и SSD, поддерживающим до 1GB/s. Я знаю, что эта машина десятилетней давности, работающая под управлением более современной ОС. Но вот скажите мне, не кривя душой, почему железо с такими характеристиками не может открывать простейшие десктопные приложения без задержки? Я подожду…Видео
Причина, по которой я использовал Mac Pro, в том, что это лучшая из имеющихся у меня машин с Windows, которая к тому же является моим повседневным помощником. Но, опять же, мне не важно, что выполнение этого сравнения на «старой» машине может оказаться «неточным». Когда я в прошлом году уходил из Microsoft, то на тот момент регулярно использовал десктопный Z4 2022 года, заряженный 4-ядерный ThinkPad с 32GB RAM, а также i7 Surface Laptop 3 с 16GB RAM. На них задержки, конечно, были меньше, но взаимодействие всё равно оказывалось медленным.
Пусть даже я согласен, что изначальное сравнение было неточным. Но, как вы видите, более корректное сравнение дало те же результаты — в чём я и не сомневался. Спустя многие годы использования компьютеров, вы вырабатываете интуицию относительно того, как всё должно работать, и доверие этому чутью вас не подводит при условии, что впоследствии вы проверяете свои предположения.
▍ Совершенствование компьютеров
Но давайте пока отвлечёмся от твитов и поговорим о том, как всё изменилось с 2000-х. В своём твите я в шутку задал риторический вопрос о том, как мы «продвигаемся» в индустрии, и предлагаю на эту тему порассуждать.
По правде говоря, мы действительно продвинулись во многих аспектах: теперь нам доступна невероятная графика и мониторы с высоким разрешением, супербыстрые сети, редактирование видео в реальном времени и многое другое. Все эти аспекты с течением лет улучшались и это правда, что для достижения текущего состояния они претерпели определённые трансформации. Вот некоторые примеры: стало намного проще общаться с близкими людьми, благодаря качественной видеосвязи; появилась возможность организовать дома потоковый кинотеатр; и прочее.
Помимо этого, мы сильно продвинулись по части ввода-вывода. Дисковый ввод-вывод всегда являлся слабым звеном прошлых систем. Дисководы были ненадёжными и медленными. CD и DVD стали чуть надёжнее, но всё равно особой скоростью не отличались. Жёсткие диски оказывались узким местом во многих смыслах. Их пропускная способность со временем улучшилась, сделав возможным, например, редактирование видео в высоком разрешении, но произвольный ввод-вывод сталкивался с физическими ограничениями —, а скорость ввода-вывода как раз, по сути, и определяет отзывчивость десктопных систем.
Затем на рынке появились SSD, и ими начали укомплектовывать настольные ПК. Эта технология оказалась переломной, потому что исправила проблему произвольного ввода-вывода. С появлением SSD загрузка ПК, запуск тяжёлой игры, открытие каталогов со множеством мелких фото или даже просто использование компьютера — всё это значительно ускорилось. Если вы сами не пережили этот переход, то будет сложно рассказать вам, насколько он улучшил юзабилити. Но сейчас пугает то, что все эти улучшения практически сведены на нет, о чём мы поговорим позже.
Хотя усовершенствование произошло не только в этом. Упростилась установка нового оборудования, повсеместно распространилась беспроводная связь и соответствующие устройства, произошла интернационализация текста и приложений (соглашусь, Unicode — это непростое и недешёвое решение)… Всё это привело к тому, что нам стало доступно больше машин для использования в различных контекстах, чем когда-либо.
Так что ситуация во многих областях действительно значительно улучшилась, и наши возможности существенно расширились. В противном случае мы бы не могли, например, обрабатывать фото с помощью ИИ на крохотном телефоне, о чём в 2000-х нельзя было и мечтать.
▍ Ужасная задержка
Хотя…никакие из этих улучшений не оправдывают ту невероятную задержку, которую мы сегодня наблюдаем в UI. Старое железо из 1999 года в комбинации с ОС того же года показывает, что отзывчивость систем существовала.1 Если уж на то пошло, то описанные мной усовершенствования должны были всё улучшить, а не ухудшить, разве не так?
Некоторые отреагировали на мои сравнения, сказав, что причиной замедления является графическая анимация и значительно увеличившиеся размеры экранов, ведущие к необходимости отрисовывать больше пикселей. То есть само наличие всех этих приятностей как бы означает, что мы должны смириться с замедлением. Что ж, это не совсем так. Смотрите сами:
Видео
Сегодня GPU используются повсеместно и снимают с CPU значительную нагрузку по обработке графики. Вид графической анимации, отвечающий за отрисовку рабочего стола, вычисляется очень легко, и это доказывает macOS с момента своего запуска: все графические эффекты на рабочем столе macOS работают мгновенно. Хотя задержка всё же присутствует в эффектах — особенно это проявляется при анимации переключения рабочего стола…О боже, как я это ненавижу —, но эти задержки обычно возникают в результате намеренных пауз во время анимации. А когда эти эффекты вносят задержку из-за того, что GPU не справляется, например, при подключении 4К дисплея к старому Mac, становится болезненно очевидно, что анимации тормозят из-за недостачи питания. Хотя в своих роликах я с таким не сталкивался, и поэтому мои беспокойства никак не связаны с анимациями и подобными эффектами.
Так что подумайте об этом с критической точки зрения. Как способность редактировать несколько видеопотоков 4К в реальном времени или возможность передавать кино в 4К может приводить к замедлению запуска таких приложений, как блокнот? Либо открытие контекстного меню на рабочем столе? Или чтение почты? Все новые возможности требуют гораздо больше ресурсов CPU и GPU, но они не должны понижать быстродействие задач, которые, по сути, привязаны к вводу-выводу. Запуск простого приложения не должен происходить медленнее, чем двадцать лет назад; реально не должен. Но мы имеем, что имеем. Возможно, причина десктопных задержек кроется в каких-то иных источниках, и у меня есть на эту тему догадки. Но сначала разберём пару примеров.
▍ Примеры
В Windows есть два наглядных примера, которые я хочу показать, и которые упоминались в твите:
- Блокнот до недавнего времени являлся нативным приложением и продолжал открываться практически мгновенно. Но после его переписывания в формате приложения UWP (Universal Windows Platform, универсальная платформа Windows) ситуация ухудшилась. Разница «до» и «после» очевидна, но всё же…это приложение по-прежнему не имеет богатого функционала, как всегда и было. Получается, возникло лишнее замедление без какой-либо выгоды для пользователя.
- Что касается Windows Terminal. Безусловно, сегодня он приятнее, чем любая из его прежних версий, но чисто визуально он намного тяжелее старой командной строки. И если сюда добавить PowerShell, то мы получим уже несколько секунд на запуск нового окна терминала, если только у вас не установлено топовое железо.
Здесь macOS показывает себя лучше, чем Windows, но и в ней есть проблемы. Посмотрите на этот пример от @AlexRugerMusic. Даже мощный M1 испытывает проблемы с запуском приложения системных настроек:
Видео
Меньше всего этим проблемам, пожалуй, подвержена система Linux, поскольку она по-прежнему ощущается довольно шустрой даже на скромном железе. Fedora Linux 38, выпущенная в апреле 2023 года, работает реально круто на micro PC 11-летней давности — несмотря на то, что в своё время его ресурсов едва хватало для Gnome или KDE. Тем не менее это всего лишь иллюзия. Как только ты устанавливаешь любое современное приложение, не разработанное конкретно под Linux…то в итоге сталкиваешься с его медленным запуском и низким быстродействием.
Также хочу сказать, что сильнейший шок у меня возник, когда я устроился в Google в 2009 году. Тогда сервисы Google Search и GMail отличались прекрасной производительностью — это были примеры для подражания. Хотя, глядя на систему изнутри, я был удивлён, насколько медленно работали все их инструменты, в особенности внутренние инструменты командной строки. Честно говоря, в том, что сегодня мы оказались в такой ситуации, я виню именно Google — со всеми их внутренними системами и ярым стремлением переходить на веб-приложения любой ценой. И тут мы подходим к…
▍ Причины
Как всё это произошло? Легко сказать «Раздувание!», но это понятие определить не так просто, потому что его можно оправдать — то, что для одного покажется раздуванием, для другого может таковым не выглядеть. В конце концов,»80% пользователей используют лишь 20% ПО, которое скачивают» (читайте Закон Парето), но ключевой вывод в том, что эти 20% для разных пользователей разные. Поэтому раздувание не обязательно находится в предлагаемой программным обеспечением функциональности; оно в чём-то ещё.
Далее, у нас есть фреймворки и слои абстракции, которые, похоже, вносят раздувание ради раздувания. Но и здесь я не уверен в корректности предположения: как доказал Rust, абстракция не обязательно должна вести к замедлению. К замедлению ведут приоритеты. Теперь уже никто не ставит производительность в приоритет, за исключением критических случаев, когда это реально важно (видеоигры, перекодирование видео и подобные задачи). Сегодня для людей (компаний) приоритетным является время разработчика.
Вот пример: вы можете не желать использовать Rust, потому что его высокий порог вхождения вынудит вас затратить больше времени на освоение языка, чем на создание с его помощью продукта, либо его длительное время компиляции будет означать, что вам придётся дольше ожидать компилятор, чем отлаживать код в продакшене. Вот ещё один пример: вы можете не хотеть разрабатывать нативные приложения, так как это означает «дублирование работы», поэтому используете кроссплатформенный веб-фреймворк, то есть Electron.
Я знаю, что Electron лёгок в работе, но со стороны пользователей были явные указания на то, что эта платформа во многом обуславливает десктопную задержку. Возьмите, к примеру, восьмую версию 1Password, которую многие, перешедшие с 7-ой версии, презирают за её медленный обновлённый интерфейс. Либо возьмём платформу Spotify, которая с самого своего зарождения делала акцент на минимальной задержке при запуске и воспроизведении, что, как вы можете знать, уже далеко не так:
Перевод:Мэтт Уокер: Я использовал Spotify 9 лет и должен сказать, что последние десктопные изменения «посадили меня на автобус страданий и отправили в город негодования».
Расмус Андерсон: Версия 2009 года: полностью нативное приложение Cocoa размером 20МБ, запускается меньше, чем за секунду, мгновенно отзывается на клики, воспроизведение обычно начинается в течение 50 мс.
Эти приложения были переписаны на Electron, чтобы предоставить унифицированный опыт по всем настольным системам и сократить затраты…но для кого? Сокращение затрат было нужно не пользователям, а компаниям, владеющим этими продуктами. Такие сокращения сказываются на каждом из нас, вызывая постоянное негодование и лишнюю потребность в апгрейде аппаратного обеспечения. Объедините такое переписывание с тем фактом, что операционные системы больше не могут повторно использовать этот тяжёлый фреймворк для всех приложений (в том же смысле, в каком использование всей RAM в качестве кэша является нерабочей идеей)…и раздувание быстро увеличится, когда вы запустите эти приложения параллельно.
Но оставим Electron в стороне. Ещё одним решением, которое наверняка вносит задержку, является массовое внедрение управляемых и интерпретируемых языков. Я знаю, они также легки в освоении, но дело в том, что у нас есть для этого причины. Возьмём Java или .NET: несколько приложений Windows были неспешно переписаны на C# и, хотя у меня нет тому подтверждения, на основе прошлого опыта я убеждён, что это может быть причиной той самой медлительности интерфейсов.
JDK и CLR проделывают прекрасную работу, оптимизируя длительные процессы (их JIT-компилятор может выполнять PGO с использованием данных реального времени), но обработка быстрого запуска даётся им с трудом. Именно поэтому, к примеру, Bazel порождает фоновый процесс сервера, чтобы компенсировать задержку при запуске, а Android пережил несколько доработок AOT-компиляции.
(Добавлено: должны существовать и другие причины, которые я не проанализировал. Как указал один человек, моё предположение, что Windows Terminal написан преимущественно на C#, оказалось ошибочным).
Подробнее об этом в Законе Вирта.
▍ Единовременные улучшения нивелируются
Закончу свой анализ пессимистичной нотой, вернувшись к аппаратным доработкам.
Конкретное улучшение, которое привнесли SSD, заключалось в единовременной трансформации. Со временем жёсткие диски действительно становились всё быстрее, но они не смогли обеспечить такой произвольный ввод-вывод, который необходим десктопным системам для быстрой работы. В этом плане переход на SSD привнёс улучшение уже другого уровня. К сожалению, получить это преимущество мы могли лишь раз: больше нет другой технологии, которая бы обеспечила подобный трансформационный переход. В результате когда выгоды, привнесённые новой технологией, оказались нивелированы халатно разработанным ПО, мы практически вернулись к начальной точке. Да, SSD становятся всё быстрее, но новые накопители не обеспечат столь же значительного прироста производительности, какой обеспечил переход с HDD на SSD.
Вы можете увидеть это сами, если попробуете использовать последние версии Windows или macOS без SSD: это почти невозможно. Эти системы предполагают наличие в компьютерах SSD, что является чисто гипотетическим предположением, но одновременно проблематичным ввиду того, о чём я писал выше. То же касается и раздувания приложений: откройте свой монитор ресурсов, взгляните на график пропускной способности дискового ввода-вывода и запустите любое современное приложение. Вы увидите длинный поток МБ, загружаемых с диска в память, и эта загрузка должна полностью завершиться прежде, чем приложение окажется отзывчивым. Именно такое раздувание Electron привносит, и именно благодаря SSD оно стало терпимым, но его можно было полностью избежать за счёт использования иных технических решений.
И это вселяет в меня беспокойство относительно Apple Silicon. Помните всю эту шумиху вокруг запуска M1? Что эти новые машины имеют превосходную производительность, невероятно живучую батарею и бесшумный вентилятор? Что ж, подождите и понаблюдайте: если мы продолжим двигаться по тому же легкомысленному пути, то все эти преимущества окажутся сведены на нет. И когда это произойдёт, будет уже слишком поздно. Модернизация производительности в существующих приложениях очень трудна с технической стороны и практически невозможна с точки зрения необходимой расстановки приоритетов.
Так что…смогут ли архитекторы компьютерных систем спасти нас с помощью очередного технологического рывка? Я бы не стал не это рассчитывать. Не потому, что не верю в рывки, а потому, что мы не должны в них нуждаться.
▍ Сноска
1. С целью более детального анализа Дэн Луу уже разбирал этот вид замедления из-за задержки в своей известной статье Computer latency: 1977–2017. Обратите внимание, что эта статья затрагивает периоды ранее 1999 года, и что по результатам его исследования минимальную задержку демонстрировали компьютеры в 1983 году. Естественно, столь древний компьютер нельзя сопоставить с рабочими нагрузками сегодняшних машин, поэтому я не думаю, что его сравнение с современными аналогами будет честным.
Выиграй телескоп и другие призы в космическом квизе от RUVDS. Поехали?
