Start Debugging

.NET 11 поднимает минимальный базовый уровень CPU до x86-64-v2

.NET 11 Preview 4 прекращает поддержку чипов x86/x64 старше 2013 года и поднимает базовый уровень JIT до x86-64-v2. Что ломается, почему и как проверить оборудование перед обновлением.

Если вы обслуживаете runner-ы CI, базовые образы Docker или что-либо работающее на старом железе, в .NET 11 есть несовместимое изменение, которое не проявляется как ошибка компилятора. Оно проявляется при запуске, на целевой машине, как отказ выполняться. Начиная с .NET 11 Preview 4, среда выполнения поднимает гарантированный минимальный набор инструкций на x86/x64 с x86-64-v1 до x86-64-v2, и Arm64 тоже получает меньшее повышение.

Что на самом деле требует новый базовый уровень

x86-64-v1 гарантировал только CMOV, CX8, SSE и SSE2. x86-64-v2 добавляет CX16, POPCNT, SSE3, SSSE3, SSE4.1 и SSE4.2. Это относится к минимуму JIT и AOT на всех трёх операционных системах (Apple, Linux, Windows). На практике последние чипы, не преодолевающие эту планку, вышли из поддержки около 2013 года, и этот уровень уже требуется Windows 11 и всеми процессорами x86/x64, официально поддерживаемыми в Windows 10.

На Arm64 минимум JIT/AOT в Windows сдвигается с armv8.0-a на armv8.0-a + LSE. Linux и Apple сохраняют свои текущие минимумы JIT, так что Raspberry Pi, предоставляющий только AdvSimd, продолжает работать.

Цели ReadyToRun (R2R) идут дальше. В Windows и Linux целью R2R теперь является x86-64-v3, который предполагает AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT и MOVBE. Цель R2R у Apple не меняется. R2R — это цель генерации кода, а не жёсткое требование: процессор ниже x86-64-v3, но на уровне x86-64-v2 или выше, продолжает выполняться, он лишь платит дополнительными затратами на jitting при запуске, потому что не может использовать предварительно скомпилированный код.

Сценарий отказа

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

The current CPU is missing one or more of the baseline instruction sets.

Нет переключателя на уровне проекта, чтобы понизить порог. Минимум JIT/AOT — это минимум.

Проверьте перед выпуском

В Linux с glibc можно спросить динамический загрузчик, какие уровни микроархитектуры поддерживает машина:

/lib64/ld-linux-x86-64.so.2 --help | grep -A4 "Subdirectories"

Вывод помечает каждый уровень как (supported) или нет:

  x86-64-v4 (not searched)
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

Если x86-64-v2 отсутствует в списке поддерживаемых, .NET 11 не запустится на этом хосте. Обычные виновники — старые агенты сборки, дешёвые VPS-инстансы, привязанные к очень старым CPU хоста, и эмулируемые окружения. Публикация AOT нацелена на тот же базовый уровень, так что бинарник Native AOT, собранный для linux-x64, несёт то же требование.

Почему Microsoft подняла нижнюю границу

Поддержка оборудования ниже того, что требует сама операционная система хоста, добавляет реальные затраты на сопровождение среды выполнения и вынуждает генерацию кода AOT по умолчанию ориентироваться на наименьший общий знаменатель, который оставляет производительность нереализованной. Поднятие базового уровня позволяет JIT и crossgen2 предполагать, что POPCNT, SSE4.2 и подобные всегда присутствуют, так что сгенерированный код становится компактнее без проверки возможностей во время выполнения. Для подавляющего большинства машин, включая каждый компьютер с Windows 11, не меняется ничего, кроме того, что код становится быстрее.

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

Источник: Новое в среде выполнения .NET 11 и заметка о совместимости по минимальным требованиям к оборудованию.

Comments

Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.

< Назад