Производительность Windows 11: тесты обновлений в цифрах

Накопительное обновление, которое Windows устанавливает во второй вторник месяца, — процесс, привычно вызывающий у пользователя смесь нетерпения и лёгкого раздражения, — в версии 24H2 стало устанавливаться заметно быстрее. Не «чуточку шустрее» и не «на глаз не отличить», а на 43,6–45,6% быстрее по сравнению с предыдущими сборками в проведённых замерах. Если раньше ежемесячный патч заставлял компьютер задуматься примерно на двадцать минут, то теперь это порядка одиннадцати. Цифра немалая, и за ней стоит не косметическая подгонка, а переработка стека обслуживания — того самого механизма, который отвечает за то, как операционная система скачивает, распаковывает и накатывает обновления.

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

Эволюция стека обслуживания: почему Windows 11 24H2 стала быстрее

Стек обслуживания (servicing stack) — это программная прослойка между серверами Microsoft и локальной системой, которая управляет жизненным циклом обновлений: от загрузки пакета до его развёртывания и финальной настройки после перезагрузки. Пользователь обычно видит только индикатор с процентами, но внутри в это время происходит довольно много операций: система разбирает манифесты компонентов, проверяет зависимости, сопоставляет версии файлов, выбирает порядок установки и решает, какие элементы действительно нужно заменить.

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

В 24H2 Microsoft изменила эту логику. Обработка манифестов стала более параллельной, а результаты отдельных проверок начали активнее кэшироваться. Иными словами, система получила возможность одновременно разбирать несколько компонентов и не пересчитывать заново уже подтверждённые зависимости, если состояние системы не изменилось.

На практике в опубликованных замерах это дало несколько разных эффектов:

• время установки накопительного обновления сократилось на 43,6–45,6%;
• офлайн-фаза, то есть период после перезагрузки, когда система завершает обновление без полноценного доступа пользователя к рабочему столу, стала короче на 33,5–39,7%;
• нагрузка на процессор во время установки снизилась на 15,3–25%.

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

Версия 24H2 — не просто очередное обновление функций, а переработка самой механики доставки патчей: стек обслуживания научился выполнять больше работы параллельно и реже повторять уже сделанные проверки.

Что меняется для обычного ПК

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

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

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

Есть ещё один, менее заметный, но важный нюанс. В 24H2 Microsoft внедрила условную загрузку (conditional downloads) для встроенных приложений, включая браузер Edge. Если стандартное приложение уже обновлено до нужной версии или его компоненты не требуют замены, система не загружает полный пакет повторно. Для крупных обновлений функций это может сократить объём загружаемых файлов примерно на 200 МБ.

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

Оптимизация для AMD Ryzen: как патчи меняют игровую производительность

Если обновление стека обслуживания — инфраструктурная история, то изменения, связанные с AMD Ryzen, интересны уже непосредственно владельцам производительных компьютеров. Здесь речь идёт не о скорости установки Windows, а о том, как операционная система и процессор взаимодействуют во время выполнения кода.

В августе 2024 года Microsoft выпустила обновление KB5041587 для Windows 11 23H2 и интегрировала аналогичные изменения в 24H2. Оптимизация была связана с предсказанием переходов (branch prediction) в процессорах AMD на архитектурах Zen 3, Zen 4 и Zen 5.

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

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

В доступных сравнениях для Ryzen на Zen 3, Zen 4 и Zen 5 средний прирост в процессорозависимых играх оценивался примерно в 10–11%, а в отдельных проектах доходил до 35%. Для Ryzen 9000 в тестах с KB5041587 на Windows 11 23H2 диапазон составлял от 0 до 13% в зависимости от приложения и характера нагрузки.

Таблицу важно читать именно как описание диапазона, а не как обещание для любого компьютера. Среднее значение не означает, что каждый Ryzen получит одинаковый прирост. Результат меняется в зависимости от поколения процессора, версии Windows, патча, видеокарты, разрешения, настроек качества и конкретного игрового движка.

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

Почему нельзя переносить результат на весь парк AMD

Патч, показавший заметный эффект на конкретных процессорах и играх, не превращается автоматически в универсальную оптимизацию для всех систем AMD. Нельзя по одному тестовому набору утверждать, что одинаковый прирост получат все Ryzen, все игры или любой компьютер с Windows 11.

Корректнее говорить так: Microsoft внесла изменения, которые способны улучшить результат в определённых процессорозависимых сценариях на системах с AMD Ryzen, прежде всего на архитектурах Zen 3, Zen 4 и Zen 5. Масштаб эффекта подтверждается тестами для конкретных конфигураций, но не является фиксированной характеристикой всей линейки.

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

Мифы и реальность версий 24H2 и 25H2: есть ли прогресс в скорости

Первые сравнения Windows 11 25H2 с 24H2 на процессоре AMD Ryzen 9 9950X показали нулевой прирост производительности — 0% в рамках этого тестового набора. Это полезный результат, но его нельзя превращать в характеристику вообще всех компьютеров и всех задач.

Он говорит о другом: на конкретной конфигурации с Ryzen 9 9950X и в использованных бенчмарках переход с 24H2 на 25H2 не дал измеримого ускорения. Если пользователь повторит тестирование в другой игре, приложении или режиме энергопотребления, итог может отличаться. Разница также способна зависеть от версии драйвера, фоновых процессов, настроек BIOS и самого экземпляра процессора.

Одно из объяснений результата связано с тем, что 25H2 использует ту же сервисную ветку, что и 24H2. Это означает, что переход между версиями не выглядит как полная замена базовой платформы с принципиально новым ядром и новой моделью планировщика. Значительная часть инфраструктурных изменений уже появилась в 24H2, поэтому у 25H2 было меньше пространства для повторного скачка в тех же бенчмарках.

При этом версия не сводится только к цифрам производительности. Новая ветка может включать пользовательские функции, изменения интерфейса, исправления совместимости и обновления безопасности. Просто наличие таких изменений не означает автоматически прироста FPS или ускорения многопоточного рендера.

Нулевой прирост в тестах Ryzen 9 9950X — это честный результат конкретного сравнения, а не доказательство того, что 25H2 одинаково ведёт себя на каждом процессоре и в каждой задаче.

Для владельца компьютера отсюда следует довольно практичный вывод. Если на системе уже установлена 24H2, переход на 25H2 не стоит рассматривать как гарантированный способ повысить игровую производительность. По имеющемуся сравнению ожидать прироста FPS только из-за смены версии не следует. Но это не то же самое, что утверждать: «обновление никогда и нигде не даст прироста». Новые исправления, драйверы и особенности конкретной конфигурации способны изменить картину.

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

Пока осторожная интерпретация выглядит убедительнее категоричной: 24H2 принесла заметные изменения в механике обслуживания и дала измеримый эффект в ряде тестов AMD Ryzen; 25H2 в сравнении на Ryzen 9 9950X не показала дополнительного ускорения. Всё остальное требует отдельной проверки.

Windows против Linux: сравнение в профессиональных многопоточных задачах

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

В многопоточных бенчмарках Ubuntu 24.04.3 LTS и 25.10 опережала Windows 11 25H2 в среднем примерно на 15% на сопоставимом аппаратном обеспечении. Однако и этот результат нужно воспринимать как характеристику конкретной методики. Сравнение имеет смысл только при одинаковом процессоре, объёме памяти, накопителе, версиях приложений, настройках компилятора и режиме энергопотребления. Кроме того, средний показатель по нескольким тестам не означает одинакового отрыва в каждом рабочем процессе.

Объяснение обычно ищут в различиях планировщиков. Linux использует CFS и его развитие EEVDF в свежих ядрах, тогда как Windows применяет собственную модель распределения потоков, тесно связанную с интерактивностью, приоритетами, классами задач и особенностями конкретной платформы.

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

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

Для студии, лаборатории или команды, которая регулярно запускает многопоточные задачи, разница в 15% может иметь практический смысл. Она сокращает время обработки и влияет на загрузку рабочих станций или стоимость облачных инстансов. Но переход на Linux нельзя обосновывать одной цифрой из бенчмарка: нужно проверить доступность нужных пакетов, плагины, аппаратное ускорение, лицензии и привычный рабочий процесс.

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

Технологии доставки обновлений: как Microsoft сокращает нагрузку на CPU

Заметное ускорение установки патчей в 24H2 — результат не одной удачной находки, а набора инженерных решений на разных уровнях стека обслуживания. Часть из них пользователь никогда не увидит в интерфейсе, но именно они определяют, сколько ресурсов уходит на обновление и сколько остаётся системе и приложениям.

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

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

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

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

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

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

Что из всего этого следует

Если свести результаты разных тестов к практической перспективе, получается довольно прагматичная картина. Версия 24H2 действительно ускорила саму процедуру обновления и снизила нагрузку на CPU во время установки — это подтверждается и в средних замерах, и в логике изменений стека обслуживания. Для игр на AMD Ryzen оптимизация предсказания переходов дала измеримый, но не универсальный эффект: в процессорозависимых сценариях он заметен, в графически ограниченных — почти не проявляется. Переход на 25H2 не стоит воспринимать как автоматическое повышение FPS: по имеющимся сравнениям прироста там нет. В профессиональных многопоточных задачах Linux в среднем быстрее, но это среднее по конкретной методике, а не универсальная характеристика любого пайплайна.

Главный практический вывод прост: обновления Windows 11 действительно способны влиять на производительность, но направление и величина эффекта всегда зависят от конфигурации, нагрузки и сценария. Слепо переносить цифру из одного теста на весь парк устройств нельзя — корректнее смотреть на методологию, повторяемость и ограничения, которые авторы тестов обычно указывают в конце материалов. Именно эта аккуратность отличает рабочую диагностику от маркетингового обещания «после обновления всё станет быстрее».